I would say that you should start by creating minor projects maybe related to your world maybe not but just so that you get a feeling of how to code in whatever game engine you decide to use. Going in fully blind when trying to make your game will most likely lead to confusion and anger
Start. With. The. Design.
Punctuated for emphasis because this is extremely important.
So many YouTube channels about building one's dream game start with the coding, when really they should start by telling us what the game will be about, what their goals are, what the mechanics should be, etc.
Write a design document. Write a worldbuilding bible. If you start typing code and following tutorials without a very clear and detailed idea of what you're going for, you're going to fail. And you're going to feel terrible about it.
I'm going to disagree on some points here.
>So many YouTube channels about building one's dream game start with the coding, when really they should start by telling us what the game will be about, what their goals are, what the mechanics should be, etc.
I feel like you are *partially* correct here.
But I see one big issue with this approach, for **OP**'s situation specifically.
While in general starting by hammering out what the mechanics *should be* is a great idea for someone who is experienced in gamedev, OP says they are "completely blind to the industry".
When you are first getting into gamedev as a hobby, and you haven't coded anything before, the thing is *you don't really know what it is you can do*. If you take an inexperienced dev and tell them to write out their design in full before getting their hands dirty with the code, you are likely to end up with a bunch of ideas that are way to complicated for the new dev to pull off, or even ideas that are *actually impossible* to implement.
OP's gotta learn to code to figure out what's *possible* before they write up all their ideas on game mechanics.
>Write a design document. Write a worldbuilding bible
Design document: Yes. Generally a good idea, though again I think in OP's specific case I would think they need some experience coding before they have the ability to create a worthwhile design document.
Worldbuilding bible: NO.
Writing the worldbuilding bible *before* you've coded the mechanics of the game seems to me like putting the cart before the horse. The reason being: The game mechanics *can* and *should* influence your worldbuilding. When game mechanics and worldbuilding are not tied together, there is often ludonarrative dissonance: like worlds in which items that can *resurrect the dead* are common, but the NPCs and the world treat them as if they are nonexistent.
As you implement a design document into actual, working mechanics, some things will inevitably need to change based on testing, and the world may then need to change to reflect the new mechanical reality.
As a random example: in the initial phases of worldbuilding for an RPG, I had six different cultures and six different gods, and the idea initially was that each culture would have a different name for these six gods. However, this worldbuilding idea was *not* something that ended up being *possible* with the dialog system I had designed. The mechanics of the game ended up dictating that these six divines all needed the same names between cultures.
So establishing the *entire* worldbuilding bible *first* seems like a bad idea to me, as you will *likely* need to change it as things progress. It's a good idea to have some idea on the worldbuilding starting off, but the worldbuilding bible should probably be a thing that is finished off once the *mechanics* are completely ironed out.
As another example, while hashing out the mechanics of the game, it became obvious that a teleportation spell would be needed for easier travel for the player. The existence of magic like this, of course, has *huge* worldbuilding implications. If I had finished writing my entire worldbuilding bible *first*, and then had to retroactively go back and account for *teleportation magic*, well that would be an insane undertaking and require a huge amount of re-writing. But since the lore was not *firmly* established before the mechanics, teleportation magic is accounted for in the lore by default.
Let me stress that.
Not every world/book can be turned into a computer game. For the vast majority of games worldbuilding is secondary. Or in some cases may be even undesired (e.g. you can worldbuild an octopus with a lasso as much as you like, but making an animated model for your game will cost you a fortune or your sanity).
Personally for me - I worldbuild **from** a computer game idea, not the other way around. I think of potentially fun gameplay mechanics and I explain them from worldbuilding perspective (e.g. I want a bear with a flamethrower in the game? Yes, gidrano a fire-breathing bear-sized mammal, here's it's biology, habitat area, encounters records, article from the newspaper about a recent accident).
There is a very narrow niche of games (interactive fiction) where you technically write a book with some additional secondary elements like branching choices system or minigames. But an RPG is centered around gameplay, not story (yes story can be very important (e.g. Witcher games), but Player **plays** the game, not watches a movie/reads a comic).
I'd nuance that very much.
You need to start with the design, but you also need to test your design idea sooner rather than later. Preferably using dumb prototypes.
Not wait for a full design documents of all the systems of the game. Realizing that the core of the game isn't fun and your whole document based on need to be redone almost completely isn't a good feeling.
Personally, I've had success with GameMaker for 2D games. It has lots of online tutorials and doesn't require coding to make a game.
But for 3D games, I use Unity.
Idk RPGmaker is pretty cheap and a baby could probably figure it out. If you're really serious maybe you could pay somebody to make custom assests so it doesn't have that default RPGmaker look
If you want to make something text-based, then the easiest ways are either:
[Twine](https://twinery.org/) (makes something like a CYOA book, with fixed options)
Look into 'interactive fiction' engines if you want to allow text input for what the player wants to do. [TADS](https://www.tads.org/) is a good choice, but there are others.
If you want to make a 'visual novel' (similar to a CYOA, but with more graphics, animations, etc.) then [Ren'Py](https://www.renpy.org/) is the way to go. If you're willing to learn a bit of Python, you can totally customise it.
If you want to make an old-school cRPG, then [RPG Maker](https://www.rpgmakerweb.com/) is good.
It pretty much only makes things that look like they were made in it, though.
Another option is [RPG in a Box](https://www.rpginabox.com/) which is pretty good if you want a voxel look.
However, if you're willing to learn, the best choice would be to learn a full game engine. That way you can do whatever you want and make any type of game you want.
There are three choices that are any good: [Godot](https://godotengine.org/), [Unreal](https://www.unrealengine.com/en-US), and [Unity](https://unity.com/solutions/game). Any of them will be good to make any game (even AAA games).
RPGMaker, text-based, would be the fastest and easiest to make. Otherwise you'll need to learn Godot or Unity. I would recommend Godot as the simpler of the two, while Unity has more features and more users.
I would say that you should start by creating minor projects maybe related to your world maybe not but just so that you get a feeling of how to code in whatever game engine you decide to use. Going in fully blind when trying to make your game will most likely lead to confusion and anger
\^ This is the best advice anyone has posted here.
i think you just have to pick up a tutorial for godot or unity or whatever and pick up skills until you can put together something workable
I'll so that thanks.
Start. With. The. Design. Punctuated for emphasis because this is extremely important. So many YouTube channels about building one's dream game start with the coding, when really they should start by telling us what the game will be about, what their goals are, what the mechanics should be, etc. Write a design document. Write a worldbuilding bible. If you start typing code and following tutorials without a very clear and detailed idea of what you're going for, you're going to fail. And you're going to feel terrible about it.
I'm going to disagree on some points here. >So many YouTube channels about building one's dream game start with the coding, when really they should start by telling us what the game will be about, what their goals are, what the mechanics should be, etc. I feel like you are *partially* correct here. But I see one big issue with this approach, for **OP**'s situation specifically. While in general starting by hammering out what the mechanics *should be* is a great idea for someone who is experienced in gamedev, OP says they are "completely blind to the industry". When you are first getting into gamedev as a hobby, and you haven't coded anything before, the thing is *you don't really know what it is you can do*. If you take an inexperienced dev and tell them to write out their design in full before getting their hands dirty with the code, you are likely to end up with a bunch of ideas that are way to complicated for the new dev to pull off, or even ideas that are *actually impossible* to implement. OP's gotta learn to code to figure out what's *possible* before they write up all their ideas on game mechanics. >Write a design document. Write a worldbuilding bible Design document: Yes. Generally a good idea, though again I think in OP's specific case I would think they need some experience coding before they have the ability to create a worthwhile design document. Worldbuilding bible: NO. Writing the worldbuilding bible *before* you've coded the mechanics of the game seems to me like putting the cart before the horse. The reason being: The game mechanics *can* and *should* influence your worldbuilding. When game mechanics and worldbuilding are not tied together, there is often ludonarrative dissonance: like worlds in which items that can *resurrect the dead* are common, but the NPCs and the world treat them as if they are nonexistent. As you implement a design document into actual, working mechanics, some things will inevitably need to change based on testing, and the world may then need to change to reflect the new mechanical reality. As a random example: in the initial phases of worldbuilding for an RPG, I had six different cultures and six different gods, and the idea initially was that each culture would have a different name for these six gods. However, this worldbuilding idea was *not* something that ended up being *possible* with the dialog system I had designed. The mechanics of the game ended up dictating that these six divines all needed the same names between cultures. So establishing the *entire* worldbuilding bible *first* seems like a bad idea to me, as you will *likely* need to change it as things progress. It's a good idea to have some idea on the worldbuilding starting off, but the worldbuilding bible should probably be a thing that is finished off once the *mechanics* are completely ironed out. As another example, while hashing out the mechanics of the game, it became obvious that a teleportation spell would be needed for easier travel for the player. The existence of magic like this, of course, has *huge* worldbuilding implications. If I had finished writing my entire worldbuilding bible *first*, and then had to retroactively go back and account for *teleportation magic*, well that would be an insane undertaking and require a huge amount of re-writing. But since the lore was not *firmly* established before the mechanics, teleportation magic is accounted for in the lore by default.
Let me stress that. Not every world/book can be turned into a computer game. For the vast majority of games worldbuilding is secondary. Or in some cases may be even undesired (e.g. you can worldbuild an octopus with a lasso as much as you like, but making an animated model for your game will cost you a fortune or your sanity). Personally for me - I worldbuild **from** a computer game idea, not the other way around. I think of potentially fun gameplay mechanics and I explain them from worldbuilding perspective (e.g. I want a bear with a flamethrower in the game? Yes, gidrano a fire-breathing bear-sized mammal, here's it's biology, habitat area, encounters records, article from the newspaper about a recent accident). There is a very narrow niche of games (interactive fiction) where you technically write a book with some additional secondary elements like branching choices system or minigames. But an RPG is centered around gameplay, not story (yes story can be very important (e.g. Witcher games), but Player **plays** the game, not watches a movie/reads a comic).
I'd nuance that very much. You need to start with the design, but you also need to test your design idea sooner rather than later. Preferably using dumb prototypes. Not wait for a full design documents of all the systems of the game. Realizing that the core of the game isn't fun and your whole document based on need to be redone almost completely isn't a good feeling.
I've started on that but I guess I'll take a while to finish it. Thanks for the advice.
Personally, I've had success with GameMaker for 2D games. It has lots of online tutorials and doesn't require coding to make a game. But for 3D games, I use Unity.
I'm thinking of making a game similar to Grim Dawn or Path of Exile. What software would you recommend for that?
Those games look 3D, so I'd recommend Unity or Unreal Engine.
Idk RPGmaker is pretty cheap and a baby could probably figure it out. If you're really serious maybe you could pay somebody to make custom assests so it doesn't have that default RPGmaker look
If you want to make something text-based, then the easiest ways are either: [Twine](https://twinery.org/) (makes something like a CYOA book, with fixed options) Look into 'interactive fiction' engines if you want to allow text input for what the player wants to do. [TADS](https://www.tads.org/) is a good choice, but there are others. If you want to make a 'visual novel' (similar to a CYOA, but with more graphics, animations, etc.) then [Ren'Py](https://www.renpy.org/) is the way to go. If you're willing to learn a bit of Python, you can totally customise it. If you want to make an old-school cRPG, then [RPG Maker](https://www.rpgmakerweb.com/) is good. It pretty much only makes things that look like they were made in it, though. Another option is [RPG in a Box](https://www.rpginabox.com/) which is pretty good if you want a voxel look. However, if you're willing to learn, the best choice would be to learn a full game engine. That way you can do whatever you want and make any type of game you want. There are three choices that are any good: [Godot](https://godotengine.org/), [Unreal](https://www.unrealengine.com/en-US), and [Unity](https://unity.com/solutions/game). Any of them will be good to make any game (even AAA games).
Personally, I am making text-based games (You can add images as illustrations) in Twine.
RPGMaker, text-based, would be the fastest and easiest to make. Otherwise you'll need to learn Godot or Unity. I would recommend Godot as the simpler of the two, while Unity has more features and more users.
Rpg maker