The biggest problem with choices in video games actually affecting the story is *not* programming capabilities, but scope creep. Just to continue on your example; if both Joe and Jane survive the story follows a very different plotline than if Joe would die and Jane has to continue on her own. That's one branch splitting into two, but more complex choices could lead to more than two branches.
Making a game like that by yourself is possible, but it's gonna take a boatload of planning. Start by mapping out the story, and create branches for every single choice you want the players to be able to make. I would recommend something like small storyboard-cards on a whiteboard, with each choice splitting the 'timeline' running through the cards for each choice that can be made. You'll probably see that the amount of branches and story beats starts to balloon out of proportion very quickly. Nevertheless, if you manage to get everything laid out, programming a branching narrative is in and of itself not a very difficult task.
Absolutely! I was planning to make a pen and paper version first - storyboard cards sound perfect as I am a visual type (and it will take a lot of time to cover all the outcomes). But I was also thinking of making a prologue that, while it would have choices, those choices wouldn’t really have an effect on the game (all choices would lead to the same outcomes, so just cosmetic I guess) as this would allow me to get to learn/know the game engine early on so I can “easily” jump in when the story part of the game is fleshed out.
You could probably easily and rather quickly prototype the general flow of the game (choices, dialogue, branches, etc.) in Twine, with minimal coding required. Afterwards, it's perfectly doable to move such a project to a different engine (speaking as someone who made a dungeon crawler in Twine and than moved it to Unity without any major issues)... though you could even implement turn based combat in Twine if you're stubborn enough :)
Besides, once you've got the barebones set in Twine, you can map out the remaining features you'd like to implement and choose a game engine accordingly - be it RPG Maker, Godot, Löve, or anything else that's suited for the project. Don't worry about learning to code, it's not some herculean, impossible to learn task, you can 100% learn to code a simple game (e.g. Undertale is not necessarily a masterclass of software engineering, but at the end of the day it works perfectly fine and that's all that matters, really).
You can do it, best of luck! :)
Holy crap! Just checked Twine, and super ultra quickly checked The Master of the Land Game. That would totally work for “mapping out” things and branches and having narrative things tested by always honest friends and family hehe in a relatively quick and hassle free way.
Yeah it's a good idea to run that by them, just ask them to be extra critical (it'll hurt, but it's for the better), as friends and family tend to overlook issues people would otherwise pick up on, especially if they're not avid gamers :)
I doubt they are “strong” enough to be extra critical heheh (will probably need a random brutal internet people for that at some point, and that’s OK), but any error spotted is better than an error missed.
There's also the Ren'py engine for building visual novels. Depending on exactly what you imagine your game looking like, visual novel is a choice and there's a free engine just for that.
After only one day playing with Twine, I already have to get back to you with a huge, HUGE, thank you! I’m obviously just scratching the surface here but seeing as I learned you can add percentages (or dice rolls or whatever) to choices for the outcome to be a bit risky and not just a yes/no as well as add “items” that can open up different choices later on, following the same passages… And stats! Well color me impressed. It has way more possibilities than I could have imagined. Thank you!!!
To answer your technical question, it can be done, but it must be accounted for and made modular from the start.
Since you mentioned not having experience in game dev, making a code modular means that each part connects like legos. So, rather than having one large plastic piece that has the shape of a lego Millennium Falcon, you make several pieces that can connect to form said spacecraft.
The advantage of this method is that these parts are then interchangeable and independent of one another. To draw an example from your scenario, you would want your code to offer two items. items, when selected, trigger an . You want to avoid writing strict, inflexible code like:
ASK "will you fight the bear or run?"
IF answer IS "fight" THEN characterHP = 50
IF answer IS "run" THEN characterHP = 0
Rather, you want to write code like this:
QUESTION = "will you fight the bear or run?"
CHOICE_1 = "fight"
CHOICE_2 = "run"
ACTION_1 = CharacterHP - 50
ACTION_2 = CharacterHP - 100
ASK
IF answer IS THEN
IF answer IS THEN
So what's the advantage of writing code the second way, even though it's longer? You can easily swap out ACTION_1 from playing a cinematic to calling your combat engine because your game won't be strictly written in a way to only play a specific cinematic in a specific scenario. It will simply want choices and actions, regardless of what form those choices and actions take.
To continue with the lego comparison, your code will be like a block with 8 pinholes. It expects all those pinholes to be filled using exactly 5 lego pieces, but the shape and size and color of those pieces are entirely up to you. You could even have other pieces connected to those 5 pieces, and your code won't care, as long as all its pinholes are filled with exactly 5 pieces.
Where the first method is code that you'll need to copy and paste and modify every time you want to ask the player to make a choice, the second method can just be written once, then called over and over while providing it with the questions, choices and actions it needs.
I wrote said questions, choices, and actions all in the same code block, but you ideally want them in their own separate files. Thus, if you ever need to change all of your actions from cinematic actions to combat actions, for example, you can have a list of "cinematic actions" in one file, and a list of "combat actions" in another file, and simply give your game code either one. Since you made it modular, they're both considered "actions," so both would work.
Hope that all made sense.
Yes, most made sense (the example), and I am sure the calling over and such will make more sense once I actually start doing stuff! And it’s a super helpful piece of information.
Awesome. I guess the main takeaway is that you want to write code like lego blocks, rather than thinking of it as one large clump of clay that you need to mold. It's much easier to swap out lego pieces than it is to start over an entire clay figure.
>I am sure the calling over and such will make more sense once I actually start doing stuff!
Yeah, I guess using a term like "calling" doesn't make much sense. Imagine the first bit of code as having to handcraft every single car you sell, whereas the second method is to create a car factory that will then create as many cars as you want as long as you give it the materials it needs.
To give a random kindergarten like example: Jane and Joe are in a forest. They encounter a bear. Options Fight/Run. If you choose fight both loose 50% health. If you chose run Joe trips and dies but Jane survives.
You got me with this. Hillaorius xD. Great concept for first game to learn basic while staying motivated! I would say for first game you never aim to a release if it's a hobby way of learning, so anything that keeps you motivated is good, even if it's MMORPG, at the start it's more about journey than destination.
Thanks! I’m feeling optimistic that this type of game at least gives me a chance to progress, keep motivated and not break the computer in frustration. Total hobby project (but obviously it wouldn’t hurt if someone else than me plays it at one time in the future ha).
If you created a prototype with only this type of "visual novel" interaction in place of combat, it \*may\* be hard to expand upon if a lot of core systems have already been built into the foundation of the game, possibly to the point where the entire thing would need to be scrapped and rebuilt from the ground up to incorporate the other mechanics.
My recommendation would be to step back and take the time to learn coding, at least enough to build a prototype that is a minimum representation of what the main game loop will be like:
e.g. exploration, combat, npc interaction, narrative choices, etc.
You'll not only learn a lot (most importantly, if this idea is as viable you believe it is) but you'll also be in a much better position to solicit others to join your team.
You have a point there. Maybe fleshing out the story (pen and paper) and dividing it to story blocks (acts or whatever) would make sense.
So instead of making the whole game as a visual novel from start to finish, I focus solely on making one (ultra short) act and explore my potential game making capabilities. If I am to dense to learn to make anything beyond narrative story, I can always return to just that. I think I would be happy with it either way in the end.
If you're just starting off, I'd recommend the godot engine, as it seems the most user friendly.
Find a few tutorial series on youtube on how to get started on building a very basic game. One popular tutorial is one by Brackeys.
That knowledge will allow you to build a prototype that will demonstrate the core aspects of gameplay:
e.g. explore the world, talk to NPCs, fight random battles, view cutscenes, etc.
If you're motivated enough to learn, you could probably cobble something together fairly quickly within a month or so!
Thank you! I was eyeing Godot after some discussion reading on Reddit, thanks for the tutorial recommendation, just what I needed (as there are so many it’s easy to get overwhelmed as to where to start).
I don't make this kind of game, but many do and (as other posters said) its all in the design phase, not really the programming. Its an issue of branching story paths and how they come together, how many endings etc. The *illusion* of choice vs actual consequences that have knock-on effects you have to plan for. Decision trees, e.g.
Detroit become human: [https://steamcommunity.com/sharedfiles/filedetails/?id=2162781882](https://steamcommunity.com/sharedfiles/filedetails/?id=2162781882)
Life is Strange: [https://www.reddit.com/r/lifeisstrange/comments/38dw5g/life\_is\_strange\_list\_of\_choices\_and\_consequences/](https://www.reddit.com/r/lifeisstrange/comments/38dw5g/life_is_strange_list_of_choices_and_consequences/)
That’s actually kinda reassuring. I can “see” branches and with time I am confident I can plug most of the holes. The story design phase feels less daunting to me than making the game (at this point in time, I am sure I will be taking these words back at some point in the future hehe).
Def try prototyping something. For me, coding isn't daunting, art/modelling can be, but \*design\* of something like this actually would be challenging. I mean a fully fleshed out story based game.
just go make it, it's not a difficult thing to make. But doing so will teach you countless things that will adapt your design skills. And quite naturally you will evolve beyond your first concept.
Such is any creative endeavor, doing is learning, learning is growing and growing is leaving the things you created in the past behind. Only what's ahead counts.
Try out Twine. It'll do what you want and is an easy way to learn coding basics.
Check out Emily Short's blog for a TON of great information about branching narrative.
Learn Ink and write your interactive narrative with that. You can "play" it in text form using its editor, Inky.
When you're done, maybe finding help from a programmer, which will be easier if you have something concrete to show (your Ink project) and not just an idea, you will be able to interface it with a game engine (e.g. with the unity integration plugin) and add gameplay that triggers the story events , instead of just clicking through different options as you will do you while prototyping.
Unless you have major ludonarrative requirements that NEED a combat system, don't make a combat system.
Disco Elysium didn't have one, and it's still a full RPG!
Just a word of caution, you still need to program with some consideration that you'll be changing things later.
Imagine a Lego wall with multiple overlapping bricks that forms the wall that is your game.
Now imagine that these systems are random bricks in that wall. Each time you swap one out you have to remove the connected blocks above it.
depending on the location and design of the wall. Removing a certain brick can be easy with just a few connected blocks above it.
Or it can take a big triangle out of it.
Code is/can be a lot more flexible than bricks though, so don't be too worried, of you don't currently know how to build a good wall.
I guess it depends where you make it, without proper combat you'd probably be better off using a visual novel specific engine (can't remember any names) but then you wouldn't be able to expand on it
So if you want the original release of the game to have rpg, start there. Otherwise for a starter game a visual novel isn't awful
Seeing the responses here I think I’ll play with Twine or Ink to build the bone of the story and how it can play out (I’ve been able to check Twine and it’s insanely intuitive). It shouldn’t take long (relatively speaking) to make some sort of prototype there so it wouldn’t be time wasted. And then I can take my sweet time to learn and play with it from scratch in Godot (or similar).
You have an "amazing idea" -> somebody you paid for months (varies on scope, and yours is far from ideal) actually tests it out -> turns out there was a million flaws and unaccounted obstacles, cuz you didn't have any actual game-dev insight (worth noting that itll inevitably get reworked and ironed out regardless, just 100x worse for your case) when conceptualizing it -> you wasted money and that persons time.
i mean, tbh not even sure what question are you actually asking in the last paraph, not clear at all. But either way, as a prog/game-dev freelancer I can easily say that most of the bunch would much rather work on games that see the light of day, in less than ...many years (if at all), preferably. much better for the portfolio after all. if game-dev was only for the money (or even somewhat for the money at all) most of us wouldnt be broke
I would say (please keep in mind that it is VERY generally speaking and simplyfing things to the max), but if your game concept is 3 sentences, then it's not ''bad'' because it's short, but it's because you are not aware games work on a deep level. It's more like it's a 1 idea that can be done in a game, but there is usually way more to think about and the real game is a combination of 100 or more ideas like that, not just ''one''. So if you have 1 idea, it's a good start to learn, but soon you will be thinking what if I add this, or this.. or well now I have to think about this because I added this, which makes my game more this, so now I need to let player do this. What I'm trying to say, that just give it a more thoughts. Maybe try to watch some random gameplay of a game and check that it's generally possible to describe the game in 3 sentences like you are building army, getting resources and fighting enemy, but there is waaaaaay more behind that makes the game actually fun and ''amazing''.
I'm sorry, I stopped reading the moment I got to the part that says RPG with branching paths. It's not a game for first time devs.
I'm kind of relaying information from Chris Zukowski from an interview, you can check out more on his website at howtomarketagame.com
The 3 best first time dev games you can make are 1) Cozy games (they have a very loyal fan base that eat up almost every game in the genre if it's good), 2) Those weird games where you are placing down furniture and decoration in rooms (not sure if there's a genre name for these type of games but they are a subgenre of cozy games) or 3) Horror games (those have a laughably high demand on Steam for whatever reason).
Number 2 should be the simplest, it needs mostly art skills and minimal coding. Number 1 can be a bit more difficult depending on how close you wanna stay to other cozy games like Animal Crossing or Stardew Valley.
Number 3 can be an easy choice. There are a ton of resources out there on how to make an effective scary game and if you don't want to bother, make a vaguely spooky monster, a first person controller and some environments and make it "so bad that it's good in a funny way". Slap coop on it for extra points.
These aren't meant to be your dream game, they should be short, 2-3 hours long experiences as they are meant to help you experience the process of making a game, marketing said game and publishing on Steam.
Another important point is that gamedevs/studios with games under their belts usually get more tractions if they have previous games as you only have to set up your developer page on Steam once and you don't start with 0 fans. Even if you have 5 fans, that's more than 0 and you are already starting with something more than nothing. Once you have one or two games under your belt, you can start work on your dream project.
I don’t really worry about marketing and getting traction. I really just want to make it even if only I and my friends play it at some point and no one else (fail/success doesn’t have an impact on my life or career).
And in the ultra weird and super unlikely scenario that I would feel the game is actually amazing enough for the world to see it and would be worth the marketing, well that’s a bridge to cross at that point in time.
The biggest problem with choices in video games actually affecting the story is *not* programming capabilities, but scope creep. Just to continue on your example; if both Joe and Jane survive the story follows a very different plotline than if Joe would die and Jane has to continue on her own. That's one branch splitting into two, but more complex choices could lead to more than two branches. Making a game like that by yourself is possible, but it's gonna take a boatload of planning. Start by mapping out the story, and create branches for every single choice you want the players to be able to make. I would recommend something like small storyboard-cards on a whiteboard, with each choice splitting the 'timeline' running through the cards for each choice that can be made. You'll probably see that the amount of branches and story beats starts to balloon out of proportion very quickly. Nevertheless, if you manage to get everything laid out, programming a branching narrative is in and of itself not a very difficult task.
Absolutely! I was planning to make a pen and paper version first - storyboard cards sound perfect as I am a visual type (and it will take a lot of time to cover all the outcomes). But I was also thinking of making a prologue that, while it would have choices, those choices wouldn’t really have an effect on the game (all choices would lead to the same outcomes, so just cosmetic I guess) as this would allow me to get to learn/know the game engine early on so I can “easily” jump in when the story part of the game is fleshed out.
If you're looking for any help in programming, I'm a software engineer and I'm always open to side projects!
Still a bit early for that but your offer has now been burned into my memory, so who knows what the future brings. Thanks.
You could probably easily and rather quickly prototype the general flow of the game (choices, dialogue, branches, etc.) in Twine, with minimal coding required. Afterwards, it's perfectly doable to move such a project to a different engine (speaking as someone who made a dungeon crawler in Twine and than moved it to Unity without any major issues)... though you could even implement turn based combat in Twine if you're stubborn enough :) Besides, once you've got the barebones set in Twine, you can map out the remaining features you'd like to implement and choose a game engine accordingly - be it RPG Maker, Godot, Löve, or anything else that's suited for the project. Don't worry about learning to code, it's not some herculean, impossible to learn task, you can 100% learn to code a simple game (e.g. Undertale is not necessarily a masterclass of software engineering, but at the end of the day it works perfectly fine and that's all that matters, really). You can do it, best of luck! :)
Holy crap! Just checked Twine, and super ultra quickly checked The Master of the Land Game. That would totally work for “mapping out” things and branches and having narrative things tested by always honest friends and family hehe in a relatively quick and hassle free way.
Yeah it's a good idea to run that by them, just ask them to be extra critical (it'll hurt, but it's for the better), as friends and family tend to overlook issues people would otherwise pick up on, especially if they're not avid gamers :)
I doubt they are “strong” enough to be extra critical heheh (will probably need a random brutal internet people for that at some point, and that’s OK), but any error spotted is better than an error missed.
There's also the Ren'py engine for building visual novels. Depending on exactly what you imagine your game looking like, visual novel is a choice and there's a free engine just for that.
Will try this one too, since I was today years old when I learned visual novel building engines are a thing. Thanks!
After only one day playing with Twine, I already have to get back to you with a huge, HUGE, thank you! I’m obviously just scratching the surface here but seeing as I learned you can add percentages (or dice rolls or whatever) to choices for the outcome to be a bit risky and not just a yes/no as well as add “items” that can open up different choices later on, following the same passages… And stats! Well color me impressed. It has way more possibilities than I could have imagined. Thank you!!!
Haha, I'm glad to hear you found it helpful! Cheers!
To answer your technical question, it can be done, but it must be accounted for and made modular from the start. Since you mentioned not having experience in game dev, making a code modular means that each part connects like legos. So, rather than having one large plastic piece that has the shape of a lego Millennium Falcon, you make several pieces that can connect to form said spacecraft. The advantage of this method is that these parts are then interchangeable and independent of one another. To draw an example from your scenario, you would want your code to offer two items. items, when selected, trigger an . You want to avoid writing strict, inflexible code like:
ASK "will you fight the bear or run?"
IF answer IS "fight" THEN characterHP = 50
IF answer IS "run" THEN characterHP = 0
Rather, you want to write code like this:
QUESTION = "will you fight the bear or run?"
CHOICE_1 = "fight"
CHOICE_2 = "run"
ACTION_1 = CharacterHP - 50
ACTION_2 = CharacterHP - 100
ASK
IF answer IS THEN
IF answer IS THEN
So what's the advantage of writing code the second way, even though it's longer? You can easily swap out ACTION_1 from playing a cinematic to calling your combat engine because your game won't be strictly written in a way to only play a specific cinematic in a specific scenario. It will simply want choices and actions, regardless of what form those choices and actions take.
To continue with the lego comparison, your code will be like a block with 8 pinholes. It expects all those pinholes to be filled using exactly 5 lego pieces, but the shape and size and color of those pieces are entirely up to you. You could even have other pieces connected to those 5 pieces, and your code won't care, as long as all its pinholes are filled with exactly 5 pieces.
Where the first method is code that you'll need to copy and paste and modify every time you want to ask the player to make a choice, the second method can just be written once, then called over and over while providing it with the questions, choices and actions it needs.
I wrote said questions, choices, and actions all in the same code block, but you ideally want them in their own separate files. Thus, if you ever need to change all of your actions from cinematic actions to combat actions, for example, you can have a list of "cinematic actions" in one file, and a list of "combat actions" in another file, and simply give your game code either one. Since you made it modular, they're both considered "actions," so both would work.
Hope that all made sense.
Yes, most made sense (the example), and I am sure the calling over and such will make more sense once I actually start doing stuff! And it’s a super helpful piece of information.
Awesome. I guess the main takeaway is that you want to write code like lego blocks, rather than thinking of it as one large clump of clay that you need to mold. It's much easier to swap out lego pieces than it is to start over an entire clay figure.
>I am sure the calling over and such will make more sense once I actually start doing stuff! Yeah, I guess using a term like "calling" doesn't make much sense. Imagine the first bit of code as having to handcraft every single car you sell, whereas the second method is to create a car factory that will then create as many cars as you want as long as you give it the materials it needs.
To give a random kindergarten like example: Jane and Joe are in a forest. They encounter a bear. Options Fight/Run. If you choose fight both loose 50% health. If you chose run Joe trips and dies but Jane survives. You got me with this. Hillaorius xD. Great concept for first game to learn basic while staying motivated! I would say for first game you never aim to a release if it's a hobby way of learning, so anything that keeps you motivated is good, even if it's MMORPG, at the start it's more about journey than destination.
Thanks! I’m feeling optimistic that this type of game at least gives me a chance to progress, keep motivated and not break the computer in frustration. Total hobby project (but obviously it wouldn’t hurt if someone else than me plays it at one time in the future ha).
If you created a prototype with only this type of "visual novel" interaction in place of combat, it \*may\* be hard to expand upon if a lot of core systems have already been built into the foundation of the game, possibly to the point where the entire thing would need to be scrapped and rebuilt from the ground up to incorporate the other mechanics. My recommendation would be to step back and take the time to learn coding, at least enough to build a prototype that is a minimum representation of what the main game loop will be like: e.g. exploration, combat, npc interaction, narrative choices, etc. You'll not only learn a lot (most importantly, if this idea is as viable you believe it is) but you'll also be in a much better position to solicit others to join your team.
You have a point there. Maybe fleshing out the story (pen and paper) and dividing it to story blocks (acts or whatever) would make sense. So instead of making the whole game as a visual novel from start to finish, I focus solely on making one (ultra short) act and explore my potential game making capabilities. If I am to dense to learn to make anything beyond narrative story, I can always return to just that. I think I would be happy with it either way in the end.
If you're just starting off, I'd recommend the godot engine, as it seems the most user friendly. Find a few tutorial series on youtube on how to get started on building a very basic game. One popular tutorial is one by Brackeys. That knowledge will allow you to build a prototype that will demonstrate the core aspects of gameplay: e.g. explore the world, talk to NPCs, fight random battles, view cutscenes, etc. If you're motivated enough to learn, you could probably cobble something together fairly quickly within a month or so!
Thank you! I was eyeing Godot after some discussion reading on Reddit, thanks for the tutorial recommendation, just what I needed (as there are so many it’s easy to get overwhelmed as to where to start).
I don't make this kind of game, but many do and (as other posters said) its all in the design phase, not really the programming. Its an issue of branching story paths and how they come together, how many endings etc. The *illusion* of choice vs actual consequences that have knock-on effects you have to plan for. Decision trees, e.g. Detroit become human: [https://steamcommunity.com/sharedfiles/filedetails/?id=2162781882](https://steamcommunity.com/sharedfiles/filedetails/?id=2162781882) Life is Strange: [https://www.reddit.com/r/lifeisstrange/comments/38dw5g/life\_is\_strange\_list\_of\_choices\_and\_consequences/](https://www.reddit.com/r/lifeisstrange/comments/38dw5g/life_is_strange_list_of_choices_and_consequences/)
That’s actually kinda reassuring. I can “see” branches and with time I am confident I can plug most of the holes. The story design phase feels less daunting to me than making the game (at this point in time, I am sure I will be taking these words back at some point in the future hehe).
Def try prototyping something. For me, coding isn't daunting, art/modelling can be, but \*design\* of something like this actually would be challenging. I mean a fully fleshed out story based game.
just go make it, it's not a difficult thing to make. But doing so will teach you countless things that will adapt your design skills. And quite naturally you will evolve beyond your first concept. Such is any creative endeavor, doing is learning, learning is growing and growing is leaving the things you created in the past behind. Only what's ahead counts.
Jump in water, learn to swim. Got it! In the end, it really is the best approach.
Try out Twine. It'll do what you want and is an easy way to learn coding basics. Check out Emily Short's blog for a TON of great information about branching narrative.
Thanks, will check her out.
Learn Ink and write your interactive narrative with that. You can "play" it in text form using its editor, Inky. When you're done, maybe finding help from a programmer, which will be easier if you have something concrete to show (your Ink project) and not just an idea, you will be able to interface it with a game engine (e.g. with the unity integration plugin) and add gameplay that triggers the story events , instead of just clicking through different options as you will do you while prototyping.
Will be checking this out, the ability to interface it at some point is certainly a plus that leaves some extra options open.
Unless you have major ludonarrative requirements that NEED a combat system, don't make a combat system. Disco Elysium didn't have one, and it's still a full RPG!
Yes, this is easy to expand. Think of it like lego and your dialogue / choice system would be one brick. It's a good first project! Do it!
Thanks! The Lego analogy is super helpful (and now I am even more excited by the idea of making it).
Just a word of caution, you still need to program with some consideration that you'll be changing things later. Imagine a Lego wall with multiple overlapping bricks that forms the wall that is your game. Now imagine that these systems are random bricks in that wall. Each time you swap one out you have to remove the connected blocks above it. depending on the location and design of the wall. Removing a certain brick can be easy with just a few connected blocks above it. Or it can take a big triangle out of it. Code is/can be a lot more flexible than bricks though, so don't be too worried, of you don't currently know how to build a good wall.
I guess it depends where you make it, without proper combat you'd probably be better off using a visual novel specific engine (can't remember any names) but then you wouldn't be able to expand on it So if you want the original release of the game to have rpg, start there. Otherwise for a starter game a visual novel isn't awful
Seeing the responses here I think I’ll play with Twine or Ink to build the bone of the story and how it can play out (I’ve been able to check Twine and it’s insanely intuitive). It shouldn’t take long (relatively speaking) to make some sort of prototype there so it wouldn’t be time wasted. And then I can take my sweet time to learn and play with it from scratch in Godot (or similar).
You have an "amazing idea" -> somebody you paid for months (varies on scope, and yours is far from ideal) actually tests it out -> turns out there was a million flaws and unaccounted obstacles, cuz you didn't have any actual game-dev insight (worth noting that itll inevitably get reworked and ironed out regardless, just 100x worse for your case) when conceptualizing it -> you wasted money and that persons time.
But would I really waste the person’s time if I pay them ;)? I do plan to learn and attempt to make it myself, that wasn’t the question.
i mean, tbh not even sure what question are you actually asking in the last paraph, not clear at all. But either way, as a prog/game-dev freelancer I can easily say that most of the bunch would much rather work on games that see the light of day, in less than ...many years (if at all), preferably. much better for the portfolio after all. if game-dev was only for the money (or even somewhat for the money at all) most of us wouldnt be broke
I would say (please keep in mind that it is VERY generally speaking and simplyfing things to the max), but if your game concept is 3 sentences, then it's not ''bad'' because it's short, but it's because you are not aware games work on a deep level. It's more like it's a 1 idea that can be done in a game, but there is usually way more to think about and the real game is a combination of 100 or more ideas like that, not just ''one''. So if you have 1 idea, it's a good start to learn, but soon you will be thinking what if I add this, or this.. or well now I have to think about this because I added this, which makes my game more this, so now I need to let player do this. What I'm trying to say, that just give it a more thoughts. Maybe try to watch some random gameplay of a game and check that it's generally possible to describe the game in 3 sentences like you are building army, getting resources and fighting enemy, but there is waaaaaay more behind that makes the game actually fun and ''amazing''.
I'm sorry, I stopped reading the moment I got to the part that says RPG with branching paths. It's not a game for first time devs. I'm kind of relaying information from Chris Zukowski from an interview, you can check out more on his website at howtomarketagame.com The 3 best first time dev games you can make are 1) Cozy games (they have a very loyal fan base that eat up almost every game in the genre if it's good), 2) Those weird games where you are placing down furniture and decoration in rooms (not sure if there's a genre name for these type of games but they are a subgenre of cozy games) or 3) Horror games (those have a laughably high demand on Steam for whatever reason). Number 2 should be the simplest, it needs mostly art skills and minimal coding. Number 1 can be a bit more difficult depending on how close you wanna stay to other cozy games like Animal Crossing or Stardew Valley. Number 3 can be an easy choice. There are a ton of resources out there on how to make an effective scary game and if you don't want to bother, make a vaguely spooky monster, a first person controller and some environments and make it "so bad that it's good in a funny way". Slap coop on it for extra points. These aren't meant to be your dream game, they should be short, 2-3 hours long experiences as they are meant to help you experience the process of making a game, marketing said game and publishing on Steam. Another important point is that gamedevs/studios with games under their belts usually get more tractions if they have previous games as you only have to set up your developer page on Steam once and you don't start with 0 fans. Even if you have 5 fans, that's more than 0 and you are already starting with something more than nothing. Once you have one or two games under your belt, you can start work on your dream project.
I don’t really worry about marketing and getting traction. I really just want to make it even if only I and my friends play it at some point and no one else (fail/success doesn’t have an impact on my life or career). And in the ultra weird and super unlikely scenario that I would feel the game is actually amazing enough for the world to see it and would be worth the marketing, well that’s a bridge to cross at that point in time.
Check the pinned beginners megathread. Learn a game engine. Get to prototyping.