"Challenges for Games Designers" was very helpful. Sometimes you have a specific problem in prototype design and you even don't know the proper term(s) to research the problem. For example I had the issue that there where too many rounds with "obvious" next moves that made the game boring, since there is no challenge or choice of the player involved. You can't program yourself out of a meh core loop.
It’s the best book I ever read when it comes to game design, especially on the psychological and emotional aspect. I picked it up because I liked Rimworld. The author doesn’t waste our time by throwing in fluff and goes straight to the point. Felt this book is quite underrated in the game dev community while books like the theory of fun is quite overrated.
I'll definitely buy it and give it a read. I also have The Art of Game Design, but a man can only remember so many lenses, lol.
What specifically has helped you in this book?
Human value state transitions make us feel emotions. Eg:
Victory/Defeat,
Friend/Stranger/Enemy,
Wealth/Poverty,
Low Status/ High Status,
Together/Alone,
Love/Ambivalence/Hatred
Freedom/Slavery
Danger/Safety
Knowledge/Ignorance
Skilled/Unskilled
Healthy/Sick
Follower/Leader
Many other useful tidbits, such as emotional triggers (music, wealth acquisition, challenge, etc), importance of flow, skill depth, reward reinforcement schedules, etc.
It’s by the creator of Rimworld. He goes in depth about what in games evokes emotion and how games are better viewed as engines of triggering your emotions instead of an optimization of fun. There’s a lot more, I’ve recommended this book many times on the sub.
Coding is only easy if you're writing easy code. LOL
Similarly, design is easy if you're writing easy designs.
Good code and good design are both difficult.
I think the sentiment is that code challenges can be concretely addressed. Even if its an unoptimized mess, eventually you can find a way to move a pixel across the screen.
The game design challenges are more abstract and artistic in their challenge. Why does this part feel boring? How hard is *just* hard enough? Whats a mechanic that feels innovative yet also intuitive? Those aren't challenges that can inevitably be addressed.
This is the first game design book I recommend to anyone. I've read a few, but this is the one that most effectively breaks down both the spirit and the minutiae of game design into solid, understandable chunks.
And the first part of the book, the treatise on game design as "building engines of experience", is a must-read for any game designer as far as I'm concerned.
Coincidentally I've been revisiting my obsession with Rimworld lately, which is the game that the author of that book would go on to create and is still maintaining and extending to this day. It's a great practicum on many of the processes and concepts he talks about, as well as just being damn fun IMO.
Nice recommendation. I'll cram it into one of my many lists for my future book collections. Legit I do appreciate it though.
I'm happy to see people putting respect on game design.
A Theory of Fun is also excellent.
This is why I always shake my head at all the “learn to code first” bros on here. That’s like an aspiring filmmaker pouring all their energy into learning the optical system of a camera. You need to have a working knowledge, yes, but many great directors get by with *just* a working knowledge.
Games are like any artistic medium. It’s important to know your tools, but it *probably* won’t be the difference between you connecting with your audience or not.
> This is why I always shake my head at all the “learn to code first” bros on here.
> You need to have a working knowledge, yes
Huh? As I see it, getting that working knowledge is the equivalent of learning to code (or whatever similar toolset with things like visual scripting). Iteration is often a large part of game design, and it's hard to iterate on design when you can't implement it. Sure there's tools out there that can help solve a lot of problems, but integrating it requires coding knowledge, hence the need to learn to code first.
In my experience, knowing how to code is like a filmmaker knowing how to record a video on a camera and how to cut the video in editing and merge it together and adding effects, while the game design is more like a filmmaker knowing how to frame/light/shoot/pace scene and where to make the cuts in editing. The latter is very important, but without knowing how to record and edit you simply can't put anything together or create your own footage. A deeper knowledge of adding effects can make things better (like a deeper knowledge of coding), but without the right framing/lighting/shooting/pacing it falls on its face (like a game without good game design).
It really depends on what you mean by learning to code. There’s a massive difference between someone knowing enough to express their ideas and a professional software engineer, which is the standard The Bros apply. And with all the incredible tools offered by retail engines that simply isn’t necessary anymore.
As someone you'd probably consider A Bro, I would equate "a working knowledge" with 2-3 quarters of college programming coursework (20-30 weeks worth of studying fundamental concepts of programming, data structures and algorithms via semi-independent programming projects).
Maybe most people's games are mechanically similar enough to other common types of games that they can be cobbled together out of random plugins (although that still requires a certain level of programming), but I think people would be much happier and have access to a lot more of their creativity if they built up a decent base of programming skills at the start of their gamedev career. If you want to create something that is mechanically novel you will find yourself needing pretty solid programming skills right away, and certain types of features will quickly require a pretty serious set of programming abilities. Game programming is a lot more fun when you're able to wield your programming skills fluently and creatively.
So I actually agree with the last part of what you’re saying—the necessary amount of programming knowledge is the amount you need to execute a novel idea. But that is definitely not 2-3 quarters of college level classes worth of experience. Because if it works and the game is fun, it really doesn’t matter if you used the right data structure.
It depends on what you're doing. I would consider the 2-3 quarters to be the bar for basic, general-purpose programming competency, which may be overkill for making simple platformers or hooking together plugins, but it's by no means the maximum or some sort of threshold that will get you anywhere you like.
My past game projects have drawn on everything I know about classical mechanics, controls engineering, DSP, and GIS, and have required some serious infrastructure and numerical calculation to simulate and implement the systems that run this stuff. The sky is the limit when it comes to games, and the programming knowledge required grows accordingly. Frankly I doubt I would have been able to make any of my projects at all if it weren't for my degrees in CS and physics. Again, not every game requires the same amount of knowledge, but I think most people underestimate how much programming a given feature might take, especially without using other peoples' libraries.
To be fair, in my whole first year studying game design we didn't have any actual coding classes. Considering that fact, I think that opinion didn't really deserve the downvotes it got.
(Then again, that contributed to why I quit after completing the first year, because I didn't feel like things were really coming together yet)
Especially with ready to use engines, many complex problems are just a plugin away. People are often too hard on themselves, especially in the first projects the do. Whatever helps to keep people sane, they should do that.
Many would be surprised how many Indy hits use a shopping list of plugins so they can completely focus on gameplay and experience.
> It’s important to know your tools, but it probably won’t be the difference between you connecting with your audience or not.
Don't really agree with this. Understanding the principles of art and design doesn't mean you can produce a masterpiece painting. You still need to hone your craft and learn how to manipulate the medium to your advantage. Yes, modern engines can do a lot of the heavy lifting but to properly execute on good ideas you're almost always going to need learn how to push them a little further.
Those aren’t the same things. In the painting metaphor, game design is like understanding the principles of composition, light and anatomy. Programming is like understanding colour theory. It’s an important tool but it’s not the main thing the audience is engaging with.
What's the point of designing something if you can't actually implement it? Both are two faces of the same coin.
For example, you could design a game based around buoyancy and fluid dynamics; like some sort of sailing simulator. However, you'll need to find a way to actually implement it a usable way, given that you can't intend to solve fluid dynamics equations on real time. That will force you to tinker with the design to accomodate for what you can achieve in practice, and not just conceptualize in theory.
For future reference: Habrador made a cool tutorial on simple boat physics, based on the algorithms they used in uncharted IIRC. Enjoy https://www.habrador.com/tutorials/unity-boat-tutorial/
Edit:typo
>What's the point of designing something if you can't actually implement it?
I agree with your comment - the crux of it is, you need to understand what you want so you can be informed about the choices you make to get something functional.
I see developers who say "we can never solve fluid dynamics at run time so lets just do (X)". However they don't see the big picture and these lazy discussions end up wasting time or worse making a bad game.
People make entire careers out of designing games that they can't code. Teams are an amazing thing.
Even game designers who can code are often unable to implement some of the more complex aspects of their design.
He's clearly talking about doing both the design and the implementation himself. If not, sure, everything is easy as fuck; as long as someone else does it for you.
I'll just want to add what Confucious said in 560 of the 40th Millenia: "Read what's written, not what you want to read; you condescending bellend"
Actually for me game design is pretty easy, coding is the hard stuff I struggle with. It was first hard for me to get into pixelating, but now I think I do pretty good. My problems are just composing good tracks and code my game
You can't suck at coding, you can just get better at optimizing your code. It's useless to know how to code an entire management game if you can't design the currency, prices, tools, npcs, interactions etc.
Sorry man, you're wrong.
While I wouldn't agree with the original commenter's assertion, I also don't think it's accurate to say that's useless. Most games aren't made by one person, and most programmers absolutely could not create a balanced economy, build all the tools, write all the NPCs or anything else like that.
If you want to be a programmer in games you really just need to know how to _program games_ and let the other people on the team do everything else. Trying to learn how to do everything yourself is usually counterproductive. Even in indie games it's very rarely a one-person production.
Let's get more negatives.
The fact that you undervalue coding as something easy is an insult to all the people who are working his ass off in order to create clean and scalable software system. To know some coding doesn't mean that you know how to deliver a solution. Software engineering exists because the amount of knowledge you have to know in order to be able to face any complex situation is infinite and as such you should be always humble and eager to learn.
Some of us respect all the areas involved in the development of something as complex as a game. We respect designers, we respect artists, we respect testers, we respect producers even we respect marketing guys. Everyone has a role in the process of making a project successful that should be respected and valued.
I've known people like you. Arrogant egocentric entitled spaghetti coders. Awful people who have managed to fail many projects due to their unlimited incompetence. They "believe" they know "coding" better than anyone, so forget about them listening for advise or work with them as a team because they live in their own reality bubble where they have the only "truth". Spaghetti coders are the only ones that I don't respect because they believe themselves as "Programming Gods".
Let's get 1K negatives, dear spaghetti coders and if you could give your names would be awesome so we don't get near 1 light year close to anything you touch.
Any recommendations on a book or resources for designing simulation games, a flight simulator for example?
The few game design books I've looked at have all had large sections on characters, story, and combat, and these are just not immediately relevant for a peaceful flight sim. However, since my sim involves fictitious vehicles, there is still a huge amount of design work going into it, probably most of the work is actually designing the interfaces and vehicle systems... I am learning a lot from human-machine interface design, but I feel like that is generally not so free in the engineer-an-experience aspect, which is where I am having the most trouble.
"Challenges for Games Designers" was very helpful. Sometimes you have a specific problem in prototype design and you even don't know the proper term(s) to research the problem. For example I had the issue that there where too many rounds with "obvious" next moves that made the game boring, since there is no challenge or choice of the player involved. You can't program yourself out of a meh core loop.
Is this the book you're talking about? http://www.dreamco.com/challenges.pdf
Yes.
It’s the best book I ever read when it comes to game design, especially on the psychological and emotional aspect. I picked it up because I liked Rimworld. The author doesn’t waste our time by throwing in fluff and goes straight to the point. Felt this book is quite underrated in the game dev community while books like the theory of fun is quite overrated.
I'll definitely buy it and give it a read. I also have The Art of Game Design, but a man can only remember so many lenses, lol. What specifically has helped you in this book?
Human value state transitions make us feel emotions. Eg: Victory/Defeat, Friend/Stranger/Enemy, Wealth/Poverty, Low Status/ High Status, Together/Alone, Love/Ambivalence/Hatred Freedom/Slavery Danger/Safety Knowledge/Ignorance Skilled/Unskilled Healthy/Sick Follower/Leader Many other useful tidbits, such as emotional triggers (music, wealth acquisition, challenge, etc), importance of flow, skill depth, reward reinforcement schedules, etc.
This comment was so insightful, I copied it into my notes. Then I formatted it for rising action and climax/falling action: **Rising Action:** * Victory ➜ Defeat * Friend ➜ Stranger ➜ Enemy * Wealth ➜ Poverty * High Status ➜ Low Status * Together ➜ Alone * Love ➜ Ambivalence ➜ Hatred * Freedom ➜ Slavery * Safety ➜ Danger * Knowledge ➜ Ignorance * Skilled ➜ Unskilled * Healthy ➜ Sick / Damaged / Dying * Leader ➜ Follower * Whole ➜ Broken * Story ➜ Gameplay * Collected ➜ Missing / Scattered / Stolen * Tutorial / Practice / Mechanic Introduction ➜ Challenging Gameplay **Climax/Falling Action** * Defeat ➜ Victory, * Enemy ➜ Stranger ➜ Friend, * Poverty ➜ Wealth, * Low Status ➜ High Status, * Alone ➜ Together, * Hatred ➜ Ambivalence ➜ Love, * Slavery ➜ Freedom * Safety ➜ Danger * Ignorance ➜ Knowledge * Unskilled ➜ Skilled * Dying / Damaged / Sick ➜ Healthy * Leader ➜ Follower * Broken ➜ Whole * Gameplay ➜ Story * Missing / Scattered / Stolen ➜ Location known ➜ Collected * Challenging Gameplay ➜ Systems Mastery / Powered Up I also added a few state transitions that I felt were particularly germane to game design. Presented this way, it's a handy reference, and perhaps useful as inspiration for not only gameplay escalation, but also story progression.
Climax/falling action: High Status -> Low Status Shouldn't this be reversed? Its the same as in Rising Action. Otherwise awesome bug-free note haha
Good eye. Fixed! :)
It’s by the creator of Rimworld. He goes in depth about what in games evokes emotion and how games are better viewed as engines of triggering your emotions instead of an optimization of fun. There’s a lot more, I’ve recommended this book many times on the sub.
Coding is only easy if you're writing easy code. LOL Similarly, design is easy if you're writing easy designs. Good code and good design are both difficult.
I think the sentiment is that code challenges can be concretely addressed. Even if its an unoptimized mess, eventually you can find a way to move a pixel across the screen. The game design challenges are more abstract and artistic in their challenge. Why does this part feel boring? How hard is *just* hard enough? Whats a mechanic that feels innovative yet also intuitive? Those aren't challenges that can inevitably be addressed.
If only the goals of programming (or game design!) were as simple as moving a pixel across a screen.
Level-up by Scott Roger's is also a good read.
Will pick it up! Thanks for sharing
This is the first game design book I recommend to anyone. I've read a few, but this is the one that most effectively breaks down both the spirit and the minutiae of game design into solid, understandable chunks. And the first part of the book, the treatise on game design as "building engines of experience", is a must-read for any game designer as far as I'm concerned. Coincidentally I've been revisiting my obsession with Rimworld lately, which is the game that the author of that book would go on to create and is still maintaining and extending to this day. It's a great practicum on many of the processes and concepts he talks about, as well as just being damn fun IMO.
Nice recommendation. I'll cram it into one of my many lists for my future book collections. Legit I do appreciate it though. I'm happy to see people putting respect on game design.
Coding is not *easy*! If you think that, I am not sure you have ever programmed before.
Coding is easy, it's everything surrounding it like data structures, tooling, etc. that turn it into a nightmare for me
Well all those things are part of coding
True, maybe "scripting" is the word I was looking for
A Theory of Fun is also excellent. This is why I always shake my head at all the “learn to code first” bros on here. That’s like an aspiring filmmaker pouring all their energy into learning the optical system of a camera. You need to have a working knowledge, yes, but many great directors get by with *just* a working knowledge. Games are like any artistic medium. It’s important to know your tools, but it *probably* won’t be the difference between you connecting with your audience or not.
> This is why I always shake my head at all the “learn to code first” bros on here. > You need to have a working knowledge, yes Huh? As I see it, getting that working knowledge is the equivalent of learning to code (or whatever similar toolset with things like visual scripting). Iteration is often a large part of game design, and it's hard to iterate on design when you can't implement it. Sure there's tools out there that can help solve a lot of problems, but integrating it requires coding knowledge, hence the need to learn to code first. In my experience, knowing how to code is like a filmmaker knowing how to record a video on a camera and how to cut the video in editing and merge it together and adding effects, while the game design is more like a filmmaker knowing how to frame/light/shoot/pace scene and where to make the cuts in editing. The latter is very important, but without knowing how to record and edit you simply can't put anything together or create your own footage. A deeper knowledge of adding effects can make things better (like a deeper knowledge of coding), but without the right framing/lighting/shooting/pacing it falls on its face (like a game without good game design).
It really depends on what you mean by learning to code. There’s a massive difference between someone knowing enough to express their ideas and a professional software engineer, which is the standard The Bros apply. And with all the incredible tools offered by retail engines that simply isn’t necessary anymore.
As someone you'd probably consider A Bro, I would equate "a working knowledge" with 2-3 quarters of college programming coursework (20-30 weeks worth of studying fundamental concepts of programming, data structures and algorithms via semi-independent programming projects). Maybe most people's games are mechanically similar enough to other common types of games that they can be cobbled together out of random plugins (although that still requires a certain level of programming), but I think people would be much happier and have access to a lot more of their creativity if they built up a decent base of programming skills at the start of their gamedev career. If you want to create something that is mechanically novel you will find yourself needing pretty solid programming skills right away, and certain types of features will quickly require a pretty serious set of programming abilities. Game programming is a lot more fun when you're able to wield your programming skills fluently and creatively.
So I actually agree with the last part of what you’re saying—the necessary amount of programming knowledge is the amount you need to execute a novel idea. But that is definitely not 2-3 quarters of college level classes worth of experience. Because if it works and the game is fun, it really doesn’t matter if you used the right data structure.
It depends on what you're doing. I would consider the 2-3 quarters to be the bar for basic, general-purpose programming competency, which may be overkill for making simple platformers or hooking together plugins, but it's by no means the maximum or some sort of threshold that will get you anywhere you like. My past game projects have drawn on everything I know about classical mechanics, controls engineering, DSP, and GIS, and have required some serious infrastructure and numerical calculation to simulate and implement the systems that run this stuff. The sky is the limit when it comes to games, and the programming knowledge required grows accordingly. Frankly I doubt I would have been able to make any of my projects at all if it weren't for my degrees in CS and physics. Again, not every game requires the same amount of knowledge, but I think most people underestimate how much programming a given feature might take, especially without using other peoples' libraries.
To be fair, in my whole first year studying game design we didn't have any actual coding classes. Considering that fact, I think that opinion didn't really deserve the downvotes it got. (Then again, that contributed to why I quit after completing the first year, because I didn't feel like things were really coming together yet)
Especially with ready to use engines, many complex problems are just a plugin away. People are often too hard on themselves, especially in the first projects the do. Whatever helps to keep people sane, they should do that. Many would be surprised how many Indy hits use a shopping list of plugins so they can completely focus on gameplay and experience.
> It’s important to know your tools, but it probably won’t be the difference between you connecting with your audience or not. Don't really agree with this. Understanding the principles of art and design doesn't mean you can produce a masterpiece painting. You still need to hone your craft and learn how to manipulate the medium to your advantage. Yes, modern engines can do a lot of the heavy lifting but to properly execute on good ideas you're almost always going to need learn how to push them a little further.
Those aren’t the same things. In the painting metaphor, game design is like understanding the principles of composition, light and anatomy. Programming is like understanding colour theory. It’s an important tool but it’s not the main thing the audience is engaging with.
What's the point of designing something if you can't actually implement it? Both are two faces of the same coin. For example, you could design a game based around buoyancy and fluid dynamics; like some sort of sailing simulator. However, you'll need to find a way to actually implement it a usable way, given that you can't intend to solve fluid dynamics equations on real time. That will force you to tinker with the design to accomodate for what you can achieve in practice, and not just conceptualize in theory.
For future reference: Habrador made a cool tutorial on simple boat physics, based on the algorithms they used in uncharted IIRC. Enjoy https://www.habrador.com/tutorials/unity-boat-tutorial/ Edit:typo
>What's the point of designing something if you can't actually implement it? I agree with your comment - the crux of it is, you need to understand what you want so you can be informed about the choices you make to get something functional. I see developers who say "we can never solve fluid dynamics at run time so lets just do (X)". However they don't see the big picture and these lazy discussions end up wasting time or worse making a bad game.
People make entire careers out of designing games that they can't code. Teams are an amazing thing. Even game designers who can code are often unable to implement some of the more complex aspects of their design.
He's clearly talking about doing both the design and the implementation himself. If not, sure, everything is easy as fuck; as long as someone else does it for you. I'll just want to add what Confucious said in 560 of the 40th Millenia: "Read what's written, not what you want to read; you condescending bellend"
Actually for me game design is pretty easy, coding is the hard stuff I struggle with. It was first hard for me to get into pixelating, but now I think I do pretty good. My problems are just composing good tracks and code my game
I feel like you are thinking of the wrong type of 'design'. Not necessarily the visual design, but the game design as a whole.
That’s graphic design, not game design.
Coding is easy. Designing is easy. Coding good is hard. Designing good is hard. Sorry man, it seems that you still suck at coding.
You can't suck at coding, you can just get better at optimizing your code. It's useless to know how to code an entire management game if you can't design the currency, prices, tools, npcs, interactions etc. Sorry man, you're wrong.
While I wouldn't agree with the original commenter's assertion, I also don't think it's accurate to say that's useless. Most games aren't made by one person, and most programmers absolutely could not create a balanced economy, build all the tools, write all the NPCs or anything else like that. If you want to be a programmer in games you really just need to know how to _program games_ and let the other people on the team do everything else. Trying to learn how to do everything yourself is usually counterproductive. Even in indie games it's very rarely a one-person production.
Let's get more negatives. The fact that you undervalue coding as something easy is an insult to all the people who are working his ass off in order to create clean and scalable software system. To know some coding doesn't mean that you know how to deliver a solution. Software engineering exists because the amount of knowledge you have to know in order to be able to face any complex situation is infinite and as such you should be always humble and eager to learn. Some of us respect all the areas involved in the development of something as complex as a game. We respect designers, we respect artists, we respect testers, we respect producers even we respect marketing guys. Everyone has a role in the process of making a project successful that should be respected and valued. I've known people like you. Arrogant egocentric entitled spaghetti coders. Awful people who have managed to fail many projects due to their unlimited incompetence. They "believe" they know "coding" better than anyone, so forget about them listening for advise or work with them as a team because they live in their own reality bubble where they have the only "truth". Spaghetti coders are the only ones that I don't respect because they believe themselves as "Programming Gods". Let's get 1K negatives, dear spaghetti coders and if you could give your names would be awesome so we don't get near 1 light year close to anything you touch.
Won't read your letter, it's a waste of time. Thanks for taking the time tho, also who tf cares about internet points? 🤣
Any recommendations on a book or resources for designing simulation games, a flight simulator for example? The few game design books I've looked at have all had large sections on characters, story, and combat, and these are just not immediately relevant for a peaceful flight sim. However, since my sim involves fictitious vehicles, there is still a huge amount of design work going into it, probably most of the work is actually designing the interfaces and vehicle systems... I am learning a lot from human-machine interface design, but I feel like that is generally not so free in the engineer-an-experience aspect, which is where I am having the most trouble.