6 ms·

I've learnt that Game Designing and Game Development are two very different things. You need a creative mind to know what mechanics will be tight and grab the a

I've learnt that Game Designing and Game Development are two very different things. You need a creative mind to know what mechanics will be tight and grab the audience. Development on the other hand requires ruthless execution. hence imo in the beginning, it's best to recreate existing games with atmost a small twist. This makes sure i'm learning one craft adeptly before moving to the next. Here's a freeboard of a game I worked on recently: https://li-quoridor.vercel.app/ https://li-quoridor.vercel.app/ [Still a work in progress]

felipemnoa 3y ago
>>Game Designing and Game Development are two very different things Right on. Took me a while to realize this. Game Design is the blue printing process of a game. Game Development is the actual building of the game. And Game Design is way harder than what I expected.
- 3737hdhd7372 3y ago
  Yeah a lot of people think of game design as just being about brainstorming cool ideas But in reality it’s actually a pretty technical job from what I’ve seen Can involve a lot of staring at spreadsheets and dealing with stats
- hesdeadjim 3y ago
  So hard. As a programmer it’s so much easier to get deep in the tech and push off the ambiguous, frustrating, yet rewarding craft of designing content. I built half the content of a VR game I released a long while back with a friend, and the only thing that got me through it was listening to talks by John Cleese on the topic of creativity. My process could be summed up as: beat my head against a wall, make something okay-ish, get frustrated, try again and again, sleep on it, and eventually repeating that enough times results in awesome stuff. But I have a hard time calling it “fun” even with the luxury of 7 years of hindsight.
  - greggman7 3y ago
    This is super true. It's why programmers like writing game engines. It's relatively well defined all the parts needed so it feels like you're making lots of progress when in reality you're just re-inventing the wheel and not doing the truly hard part, the actual design and content creation. I'm super guilty of it myself.
  - hypertele-Xii 3y ago
    I'm polar opposite - ideas coming out the wazoo, like on average 1 idea per day, after decades of research into game design, but I dread moving into production and programming. Not for lack of experience, as chief of infotech I brought business-grade software projects from whiteboard to screen, but talking to a computer is just tedious. So much plumbing.
tarruda 3y ago
I want to begin game development as a hobby, but I'm unsure where to start. I did follow through https://learnopengl.com/ https://learnopengl.com/ a few years ago, and while it was a very interesting experience, I imagine I would need to use an existing engine to be productive. Do you recommend any books and tutorials aimed at experienced programmers with 0 knowledge of game development/design?
- krapp 3y ago
  Just start with a framework like Godot. There are plenty of tutorials online. If you really want to go low level with it, though, my personal sweet spot is C, Lua/LuaJIT and SDL2. Although practically speaking C++ is probably better.
  - tarruda 3y ago
    I will keep that in mind, thanks. My initial research suggest that Godot games are written in C#. Since you use C/SDL2, do you code directly your own OpenGL engine?
    - krapp 3y ago
      I don't use OpenGL. I probably should, and this year I'm planning on getting into Blender and 3D (but through Godot) but everything I do in SDL is 2d and sprite based, and SDL handles pushing the triangles/quads on its own. Also, Godot games are also written in its native scripting language (GDScript) and it supports other languages, although I don't know how well, or how up to date anything is.
    - PsylentKnight 3y ago
      > My initial research suggest that Godot games are written in C# There are a few supported languages (including a custom Python-like language called GDScript). C# is just just one of them.
  - alectroem 3y ago
    I would highly recommend starting with a fantasy console such as Pico-8 or TIC-80. They remove the temptation to start by building a game engine from scratch, and instead help you focus on actually creating games! Plus they have great communities, complete docs, and simple apis.
derefr 3y ago
> hence imo in the beginning, it's best to recreate existing games with atmost a small twist ...if your goal is to do game development. If your goal is to do game design, though, then the place to start is making paper prototypes of your game mechanics. Almost anything turn-based can be prototyped on a tabletop with stuff you have lying around the house, and some rules about how you and your friends should move things. (For something like an RPG, you may want to write a few little calculator scripts for calculations the game would hide from the players, to run on a laptop at the table, just so everyone doesn't get dragged down doing hours of math that wouldn't actually be part of a player's experience of the game. But "a calculator script" is still a far cry simpler than a game engine!) Reflex-based video games are harder to prototype, but can often be tested "by analogy" to physical-movement games. Think: testing a design for a new FPS, by designing the mechanics as a set of LARP-y mods over paintball/airsoft/lasertag. For a reflex-based video game where the player avatar is expected to be superhuman (e.g. most platformers/adventure games), you might not be able to test the mechanics directly, but you can at least create paper rubrics — e.g. threat-radius circles for attacks. You can then do level design by building physical dioramas out of blocks (Lego — esp. Technics, to have parts of the diorama move — is great for this!) and then "testing" using your paper rubrics to ensure each course is at least possible. This isn't so great an idea — unlike the previous prototyping strategies, this one won't really indicate whether your game idea is fun to play — but it's at least something you can do to iterate on an existing game concept without constantly having to program in each new marginal idea. The only kind of game that's near-impossible to prototype without actually programming anything, is an "artsy" game where the mechanics play with lighting / mirrors / illusions / etc. in a way that doesn't line up with things that are physically possible in the real world. So... don't try to design one of those as your first game. :)
- meheleventyone 3y ago
  Having tried to get on board with and use paper prototypes for digital games I’d largely disagree with this. Unless the mechanics are complementary to a board game then you’re largely not going to learn anything useful working this way. I’ve found that even in the case of digital games that do have good parity you learn a lot more as soon as you ditch paper and start working in the native format. With the reflex case this just gets worse, as the prototype medium gets ever further from any congruence to what you want to make. There’s just too much missing in what it feels like to play the game. From the affordances digital games have, to the feedback and automated book keeping.
bcrosby95 3y ago
In professional game creation (trying to avoid the two "D" words you used here) the two are intertwined. You need to iterate on design, and to do that you need to develop. Basically no professional game comes out as it was originally envisioned, and oftentimes a nearly complete version is tossed out because it just sucks too much.
- ugh123 3y ago
  In a more "traditional" software team or even medium sized studio, I think the two are a bit more specialized with individuals focusing on each, still with some influence on the other i'm sure.
  - meheleventyone 3y ago
    They are but you’re still working together to make the same thing so the process is intertwined. This is also why you have several specializations for example gameplay engineer or technical designer on larger teams that bridge the gap.
adamrezich 3y ago
there's both pros and cons to both punching above and below one's weight, in terms of programming ability. I learned a great deal from working on overly-ambitious projects—both what to do, and, more importantly, what not to do—but it wasn't until much later that I learned the value of making something that seemed, to me, to be "well below my skill level". these days, I can't advocate strongly enough for programmers, especially aspiring game developers, to first set out to do as you say and recreate a simple, already existing game first, then play around with modifying its rules, making its presentation more spiffy, and so on. people often get enamored with success stories like, "well, [indie game you've heard of] was the first game project [creator] ever worked on, and he spent years working on it and nothing else, and now it's popular and successful and everyone you know has heard of it, so why shouldn't I just go about things the same way?" well sure, you can try to go about things the same way, but there's very, very little guarantee of success in doing things that way—not just in terms of sales or popularity, but in terms of even just actually finishing making what you set out to make. it's often surprising just how much work it takes to implement everything necessary—even for a seemingly very simple, minimal game—and going through the process of figuring out what is needed to make it, and then making it, is an absolutely invaluable learning tool. this is especially true if you've never done any sort of game design before. some people like to make video games by "paper prototyping" first, and while this is certainly an option, I find that the best, most interesting games are made by a programmer or team of programmers who have an idea, start formalizing said idea into code, and then sort of "discover" the rest of the game's design by exploring the possibility space that the formalized initial design idea provides, by playtesting and writing more code. but all of this is a lot easier once you have a few finished small game projects under your belt, and learned some of the basic game development insights along the way.
grantismo 3y ago
Small twists are great. It's interesting how dramatically different strategies and playstyles emerge from such twists. I made a wordle spinoff which has attracted far more users than I ever would have imagined https://www.polygonle.com https://www.polygonle.com
- Aerroon 3y ago
  I'm curious: how did people find out about the game in the first place? Ie how did you attract the first players?
SushiHippie 3y ago
FYI the layout is completely mangled on firefox on android :( https://ibb.co/pJGYF9S https://ibb.co/pJGYF9S

felipemnoa 3y ago

>>Game Designing and Game Development are two very different things Right on. Took me a while to realize this. Game Design is the blue printing process of a game. Game Development is the actual building of the game. And Game Design is way harder than what I expected.

3737hdhd7372 3y ago
Yeah a lot of people think of game design as just being about brainstorming cool ideas But in reality it’s actually a pretty technical job from what I’ve seen Can involve a lot of staring at spreadsheets and dealing with stats
hesdeadjim 3y ago
So hard. As a programmer it’s so much easier to get deep in the tech and push off the ambiguous, frustrating, yet rewarding craft of designing content. I built half the content of a VR game I released a long while back with a friend, and the only thing that got me through it was listening to talks by John Cleese on the topic of creativity. My process could be summed up as: beat my head against a wall, make something okay-ish, get frustrated, try again and again, sleep on it, and eventually repeating that enough times results in awesome stuff. But I have a hard time calling it “fun” even with the luxury of 7 years of hindsight.
- greggman7 3y ago
  This is super true. It's why programmers like writing game engines. It's relatively well defined all the parts needed so it feels like you're making lots of progress when in reality you're just re-inventing the wheel and not doing the truly hard part, the actual design and content creation. I'm super guilty of it myself.
- hypertele-Xii 3y ago
  I'm polar opposite - ideas coming out the wazoo, like on average 1 idea per day, after decades of research into game design, but I dread moving into production and programming. Not for lack of experience, as chief of infotech I brought business-grade software projects from whiteboard to screen, but talking to a computer is just tedious. So much plumbing.

tarruda 3y ago

I want to begin game development as a hobby, but I'm unsure where to start. I did follow through https://learnopengl.com/ https://learnopengl.com/ a few years ago, and while it was a very interesting experience, I imagine I would need to use an existing engine to be productive. Do you recommend any books and tutorials aimed at experienced programmers with 0 knowledge of game development/design?

krapp 3y ago
Just start with a framework like Godot. There are plenty of tutorials online. If you really want to go low level with it, though, my personal sweet spot is C, Lua/LuaJIT and SDL2. Although practically speaking C++ is probably better.
- tarruda 3y ago
  I will keep that in mind, thanks. My initial research suggest that Godot games are written in C#. Since you use C/SDL2, do you code directly your own OpenGL engine?
  - krapp 3y ago
    I don't use OpenGL. I probably should, and this year I'm planning on getting into Blender and 3D (but through Godot) but everything I do in SDL is 2d and sprite based, and SDL handles pushing the triangles/quads on its own. Also, Godot games are also written in its native scripting language (GDScript) and it supports other languages, although I don't know how well, or how up to date anything is.
  - PsylentKnight 3y ago
    > My initial research suggest that Godot games are written in C# There are a few supported languages (including a custom Python-like language called GDScript). C# is just just one of them.
- alectroem 3y ago
  I would highly recommend starting with a fantasy console such as Pico-8 or TIC-80. They remove the temptation to start by building a game engine from scratch, and instead help you focus on actually creating games! Plus they have great communities, complete docs, and simple apis.

derefr 3y ago

> hence imo in the beginning, it's best to recreate existing games with atmost a small twist ...if your goal is to do game development. If your goal is to do game design, though, then the place to start is making paper prototypes of your game mechanics. Almost anything turn-based can be prototyped on a tabletop with stuff you have lying around the house, and some rules about how you and your friends should move things. (For something like an RPG, you may want to write a few little calculator scripts for calculations the game would hide from the players, to run on a laptop at the table, just so everyone doesn't get dragged down doing hours of math that wouldn't actually be part of a player's experience of the game. But "a calculator script" is still a far cry simpler than a game engine!) Reflex-based video games are harder to prototype, but can often be tested "by analogy" to physical-movement games. Think: testing a design for a new FPS, by designing the mechanics as a set of LARP-y mods over paintball/airsoft/lasertag. For a reflex-based video game where the player avatar is expected to be superhuman (e.g. most platformers/adventure games), you might not be able to test the mechanics directly, but you can at least create paper rubrics — e.g. threat-radius circles for attacks. You can then do level design by building physical dioramas out of blocks (Lego — esp. Technics, to have parts of the diorama move — is great for this!) and then "testing" using your paper rubrics to ensure each course is at least possible. This isn't so great an idea — unlike the previous prototyping strategies, this one won't really indicate whether your game idea is fun to play — but it's at least something you can do to iterate on an existing game concept without constantly having to program in each new marginal idea. The only kind of game that's near-impossible to prototype without actually programming anything, is an "artsy" game where the mechanics play with lighting / mirrors / illusions / etc. in a way that doesn't line up with things that are physically possible in the real world. So... don't try to design one of those as your first game. :)

meheleventyone 3y ago
Having tried to get on board with and use paper prototypes for digital games I’d largely disagree with this. Unless the mechanics are complementary to a board game then you’re largely not going to learn anything useful working this way. I’ve found that even in the case of digital games that do have good parity you learn a lot more as soon as you ditch paper and start working in the native format. With the reflex case this just gets worse, as the prototype medium gets ever further from any congruence to what you want to make. There’s just too much missing in what it feels like to play the game. From the affordances digital games have, to the feedback and automated book keeping.

bcrosby95 3y ago

In professional game creation (trying to avoid the two "D" words you used here) the two are intertwined. You need to iterate on design, and to do that you need to develop. Basically no professional game comes out as it was originally envisioned, and oftentimes a nearly complete version is tossed out because it just sucks too much.

ugh123 3y ago
In a more "traditional" software team or even medium sized studio, I think the two are a bit more specialized with individuals focusing on each, still with some influence on the other i'm sure.
- meheleventyone 3y ago
  They are but you’re still working together to make the same thing so the process is intertwined. This is also why you have several specializations for example gameplay engineer or technical designer on larger teams that bridge the gap.

adamrezich 3y ago

there's both pros and cons to both punching above and below one's weight, in terms of programming ability. I learned a great deal from working on overly-ambitious projects—both what to do, and, more importantly, what not to do—but it wasn't until much later that I learned the value of making something that seemed, to me, to be "well below my skill level". these days, I can't advocate strongly enough for programmers, especially aspiring game developers, to first set out to do as you say and recreate a simple, already existing game first, then play around with modifying its rules, making its presentation more spiffy, and so on. people often get enamored with success stories like, "well, [indie game you've heard of] was the first game project [creator] ever worked on, and he spent years working on it and nothing else, and now it's popular and successful and everyone you know has heard of it, so why shouldn't I just go about things the same way?" well sure, you can try to go about things the same way, but there's very, very little guarantee of success in doing things that way—not just in terms of sales or popularity, but in terms of even just actually finishing making what you set out to make. it's often surprising just how much work it takes to implement everything necessary—even for a seemingly very simple, minimal game—and going through the process of figuring out what is needed to make it, and then making it, is an absolutely invaluable learning tool. this is especially true if you've never done any sort of game design before. some people like to make video games by "paper prototyping" first, and while this is certainly an option, I find that the best, most interesting games are made by a programmer or team of programmers who have an idea, start formalizing said idea into code, and then sort of "discover" the rest of the game's design by exploring the possibility space that the formalized initial design idea provides, by playtesting and writing more code. but all of this is a lot easier once you have a few finished small game projects under your belt, and learned some of the basic game development insights along the way.

grantismo 3y ago

Small twists are great. It's interesting how dramatically different strategies and playstyles emerge from such twists. I made a wordle spinoff which has attracted far more users than I ever would have imagined https://www.polygonle.com https://www.polygonle.com

Aerroon 3y ago
I'm curious: how did people find out about the game in the first place? Ie how did you attract the first players?

SushiHippie 3y ago

FYI the layout is completely mangled on firefox on android :( https://ibb.co/pJGYF9S https://ibb.co/pJGYF9S