I think it strongly depends on what your goal is and what genre you plan on doing. But, I pretty much design in the way of:
1) Have Cool Game Idea
2) Research and Analysis of the existence of similar Cool Game Ideas
3) Research and Analysis of everything related to Goal and Genre
4) Fine Tune until Game Design Document is complete
Is anyone else following these or similar steps?
I'm currently designing something like a Tactical/RPG, probably the most complicated and time consuming thing to work on. But hey, it's the Dream.
At the moment I got 70+ pages of stuff on a monolithic file. I imagine things could get complicated later and I should have multiple files, but thinking about it more, I feel like a few monolithic files might be best even if I end up repeating info. Because trying to separate all the multiple connected systems into their own files seems impossible and worse. I could be wrong.
Well, if anyone has anything to say and have a discussion about this or any tips, if working on something similar, would be nice to have something else to brainstorm about.
If you are working on Tactical, RPGs, Strategy, 4Xs and maybe boardgames, games with complexity, I'm very interested on your opinions and workflows.
ID:2561412
 Apr 13 2020, 3:47 pm
|
|
Hmm, maybe your #4 is happening because you start #2 too quickly?
Not saying I'm immune to #4, of course, but it seems that your #2 and #3 aren't connected to the #1. Like walking a long distance to the wrong direction. xD | |
I think you have to search what's the "fun" in the game. Then you discover it you must work on it
You need to have some content to find the "fun", but then you find it you will have a right direction | |
(Let me say that "fun" can be defined as "purpose" or "point of the game" here.)
Is there not enough examples of what is "fun" out there already? And not just "fun" in general but what is "fun" to you personally. For example, I don't think you need to make Dark Souls to understand how the concept and decisions in game-play are supposed to be "fun". Why? Because those concepts and decisions were already created many years ago. Granted, if you care about resume building, to get a job, then having examples about all your projects is helpful. But if you are more interested in the dream/indie then why start something you aren't certain of? Just imagine going thru the work and then not finding the fun. If your goal wasn't "resume building", that's quite the failure. Another way I can say it is if you can't figure out the "unique selling point" of what you want to do then it's totally not time to start the project. The "USP" can be anything. But I doubt it's the basics of a genre. | |
1) Someone asks me to make their thing for money.
2) I make the thing. 3) They pay me. | |
Nadrew wrote:
1) Someone asks me to make their thing for money. Good, you're here. Can you contribute to the topic? | |
He did contribute. You asked, "How do you game design?" He provided an answer; it just wasn't several paragraphs long. Not everyone has a massive GDD or does research when designing a game.
As for how I game design: 1) Have a general concept in mind. 2) Prototype it. 3) Get feedback. 4) Refine it. 5) Go back to 3) until satisfied or bored; usually the latter. | |
Lige wrote:
He did contribute. You asked, "How do you game design?" He provided an answer; it just wasn't several paragraphs long. Not everyone has a massive GDD or does research when designing a game. Designing is not the act of programming it. He pretty much said he takes someones design and implements it. And that is unrelated to the topic. | |
2DExtremeProductions wrote:
Designing is not the act of programming it. That is logically true, but not necessarily a good philosophy to have while actually designing. Design and implementation are obviously linked. Part of my point in the last post was to imply that the implementation part is actually more important than the design part. All cool ideas are cool, but it's only when they are implemented well that they become great games. I'm sure many designers out there just say "yeah, well that's the programmer's job to make it work." Maybe in a large company that's okay and expected... on the other hand, maybe that often leads to high production value but little inspiration. In the indie world, you might have just one designer, and just one programmer. Or, you are one person doing it all. If the designer comes up with 70 pages of notes that have no consideration to the actual code that will make those ideas come alive, is that really a good design? I do write design notes sometimes, but I always try to have the implementation in mind while doing so. It's one of the advantages to working alone - my left arm knows what my right arm is doing. I know the limitations of the platform I'm using. I know my own programming and graphic abilities. If there's a way to make it so that the design flows along with the implementation, I try to go for that. I don't have a bunch of workers whose time I can waste and still make a profit - I'm just creating something for the love of creating it, which means I have abundant inspiration but not a ton of time. So, I try to design my projects in a way that, if you were to present the design to a seasoned programmer, they would think it to be very possible to implement. Of course, it's hard to know about things you've never programmed before, which is why I jump right in to coding as soon as I know what kind of "engine" I need to build. I was half-joking about step #4, losing all motivation. Sometimes that's the case, but other times the effort required seems too much, or the engine works fine but I'm not feeling like it will turn into a super fun game, or I find that my initial prediction about what I needed to program was way off and that I should scrap it and start again. Anyway, my main point is that coding and designing are irreparably linked, and all the cool ideas in the world can't mask a game engine that sucks. I think over-designing can really bog down production, and often results in a product that has lots of bells and whistles but a weak core experience. | |
Magicsofa wrote:
That is logically true, but not necessarily a good philosophy to have while actually designing. Design and implementation are obviously linked. Part of my point in the last post was to imply that the implementation part is actually more important than the design part. All cool ideas are cool, but it's only when they are implemented well that they become great games. I'm interested to know how objectively true that is. What part of an implementations purpose cannot be figured out in the design stage? Like, I understand this making sense for AAA development at the level of pushing the boundaries of what is possible on specific hardware. Because then the implementation has an effect on the design. But, anything less than that? No. Lets simplify and state that this false-game example limits a games design to SNES/Genesis level quality, we use DM or GMS or any other 2D concentrated engine. How is implementing Super Meat Boy any different than knowing what the mechanics of Super Meat Boy achieve on it's design? Knowing the design I can already expect what the game will be like. The power in computers now are far superior than years ago. Which means, I have no doubt of it being able to be implemented. Magicsofa wrote: If the designer comes up with 70 pages of notes that have no consideration to the actual code that will make those ideas come alive, is that really a good design? You mean designing in pseudo-code to give a programmer a leg up or something else? Please elaborate. Magicsofa wrote: If there's a way to make it so that the design flows along with the implementation, I try to go for that. Can you give an example? Magicsofa wrote: I was half-joking about step #4, losing all motivation. Sometimes that's the case, but other times the effort required seems too much, or the engine works fine but I'm not feeling like it will turn into a super fun game, or I find that my initial prediction about what I needed to program was way off and that I should scrap it and start again. Can you talk more about those failures? Magicsofa wrote: I think over-designing can really bog down production, and often results in a product that has lots of bells and whistles but a weak core experience. But isn't a weak core experience a major sign of bad design? And hence, under-designing. | |
2DExtremeProductions wrote:
How is implementing Super Meat Boy any different than knowing what the mechanics of Super Meat Boy achieve on it's design? Player experience does not have a direct linear relationship to hardware or platform. Within the limitations of the platform you are working on, you can still have major differences in the "feel" of the game. How fast or slow it moves, what it sounds like, how the controls respond, how easy it is to understand what to do, what are the menus like... and on and on. The designer might say "I want the player to be able to jump," but the programmer might ask "How high? How fast? How long?" Don't you think they should work together on that? But isn't a weak core experience a major sign of bad design? And hence, under-designing. No. It depends on why the experience is weak. So for example, if the story is well written and interesting but the methods of delivery are annoying (such as lots of dialogue that you can't skip even if you're done reading) then it's bad implementation. If the interface feels really good and the dialogue -can- be skipped, and whatever functionality you want is working perfectly...but the story is garbage, then that's bad design. | |
Magicsofa wrote:
Player experience does not have a direct linear relationship to hardware or platform. Within the limitations of the platform you are working on, you can still have major differences in the "feel" of the game. How fast or slow it moves, what it sounds like, how the controls respond, how easy it is to understand what to do, what are the menus like... and on and on. The designer might say "I want the player to be able to jump," but the programmer might ask "How high? How fast? How long?" Don't you think they should work together on that? Well, no. If the designer just says "I want the player to jump." Then that is not a designer. Jumping should have a purpose, an explicit purpose and that purpose provides an idea of what the values the programmer will end up using. So the programmer shouldn't have to ask those questions because that's the job of the designer to already have answered. Sure the programmer ends up implementing the necessary calculations to make the jump possible but the designer defines the role, rules and reasons for the act of jumping. For example, making the jump high enough so that you can barely get hold of a far away ladder with certain death if you were to not reach it, would probably provide the player with some anxiety, excitement and relief upon grabbing on. Magicsofa wrote: No. It depends on why the experience is weak. So for example, if the story is well written and interesting but the methods of delivery are annoying (such as lots of dialogue that you can't skip even if you're done reading) then it's bad implementation. If the interface feels really good and the dialogue -can- be skipped, and whatever functionality you want is working perfectly...but the story is garbage, then that's bad design. But you don't have to implement the story, to know that the story is garbage. Nor do you have to implement the dialogue to know that a missing Quality of Life "feature" of skipping it is less likable. Maybe "implementation" should be defined better. Because to me, those things mentioned are mostly bad design or a lack in design. And for sure could have been avoided by design. What is a badly implemented car? What is a badly implemented house? What is a badly implemented game? Dragonball Z Sagas? Is Dark Souls a badly implemented action game? Is Bayonetta a badly implemented action game? | |
As for how I game design: +1 | |
2DExtremeProductions wrote:
Maybe "implementation" should be defined better. It's when programmers and artists take your 70 pages and make them actually happen. I hope you're paying them enough :P | |
Exactly what I have been stating. Thank you for the responses, always looking for a process better than mine.
| |
1. Have a cool idea
2. Think about the most fundamental programming that needs to be done to make that idea work. So for a tactical RPG, you might need players to walk around and then be sent to a battle screen where they can have turn-based battles using different abilities and movement.
3. Spend some time programming that basic system using thrown-together graphics and content. It doesn't really matter how good it looks or if the first three abilities you come up with make any sense. Just get the turn-based system working, and try to make sure it's easy enough to add content later. So for example, some abilities might use mana, while others don't or use a different resource. So, I try to think ahead a little bit to make sure it's easy to add a new ability with whatever type of cost I want.
4. After successfully creating a very basic system, lose all motivation to continue after fantasizing too much about some other cool idea.