If you are new to gamedev, I wouldn’t recommend trying to make an RPG as your first game. They tend to be kind of like making multiple games in one; you have to make a game that is the map screen, a game that is the battle system, and a tiny game that is all the menus you will have to build. It’s fairly broad in scope so you’ll be stuck on what to do because there will be so many things to do.
What I would suggest is to try to build the simplest part of your game you can make standalone first. In your case, try to make the match three part. That also happens to be the keystone of your game since it’s the battle system so you can prototype it and see if you can make it fun to start with. Once you have that pretty nailed down you can start to implement more and more RPG elements.
I’m partial to the LÖVE framework since I’ve been using it for a while and it’s pretty easy since lua is a simple language. Doing this is going to be very programming-forward since you’ll be building your game engine. If that doesn’t sound good to you start learning Godot. Unity is probably easier to learn and use if you are ok with proprietary software with legal encumbrances (they are the guys who were trying to get studios to pay more retroactively).
Very good advice imho. I want to echo that an rpc is usually a lot of work. Both like what Akir is saying about building many games in one, but also when it comes to content. There's usually a lot of dialog, loads of art for every location, many characters that need art, animations, lots of world design, etc... I also suggest doing what Akir is already saying, implement the match three to a degree that you're happy with it, polish it as much as you have the energy for, you're going to learn a lot in that process. And then start adding onto that.
About the game idea itself, I think it can work, this is all about execution and balancing the different aspects against each other.
I do want to stress that it wouldn't be a deep RPG, so no dialogue, navigable maps, no complex inventories or in depth world design, not even a controllable character outside of tapping around the inside the saferoom for them to walk around to where you tapped. Also probably not a lot of characters outside of the player character and the enemies.
The RPG elements I'd be borrowing are more the loot, character XP leveling & attributes, magic & spells, items, gear, and upgrading spells, weapons and gear. But within a limited framework.
Like the idea is that the player character selects their weapons/spells and chooses 2 items(potions, smoke bombs, etc) to take with them on the run, then when outside the saferoom, PC auto runs along a 2D corridor until they get to an enemy, combat is initiated, and after combat is complete character continues to run. Match 3 can be used outside of combat to heal, replenish mana, or temporarily boost stats between enemy encounters depending on items selected at the saferoom, rinse & repeat until next saferoom. Enemies get harder, have environmental effects, etc.
I pick up a lot of hobbies, and it's not that I want to develop a game, I want to develop this game. Haha
So it's not a full RPG, it's a relatively light RPG. So there's no map, at least not one you can navigate, you won't control the character movement, there isn't any extensive menus, there's no inventory management, no complex dialogues or quests, the combat is entirely dictated by matching the correct match-3 tiles, so combat isn't the same as typical RPGs.
I guess, at least in my head, I'm having a difficulty separating the two systems the way I want them to work together. But I mean yes, nailing the match-3 mechanics is definitely the first on the todo list.
But I am planning the RPG elements to be very basic, so not a deep RPG, but deep enough to mesh with the match-3.
Basic Character Attributes. Tied both to things like spell slots, weapon types, damage, and increase spawn chance of associated tile types during run.
Gear Slots. Help with defense, has enchantments for bonuses to stats or item based spells, etc. Dictates your weapons and shield.
You can only equip 1-2 items per dungeon run. This will dictate the kinds of item tiles that will appear on the board like potions, smoke bombs, or antidotes.
Spells & Combat - Probably the most complex system but not in the typical RPG sense, but it's entirely based on match-3 game mechanics. When you match 3 combat tiles, that's a basic attack. Match 4 tiles and it's a heavy attack that creates a combo tile. Mixing combo tiles with other tiles create all sorts of crazy spell combinations. Like match a fireball magic tile with a sword combo tile and you get a flaming sword attack. Match an Ice/Frost spell tile with a shield and you get an Ice wall defense. Match a shield combo tile with a sword tile and you get a charging shield attack. Match a throwing knife tile with an ice spell combo tile and you cast raining ice shards on enemy. Match a sword combo tile with an ice combo tile and you summon a giant ice sword that hits the enemy. Match a potion combo tile with a sword tile, and you get a vampire type hit where you get healed for the amount you hurt the enemy. And then matching combo tiles with other combo tiles things get even more crazy. The idea is to "collect" all the different combo moves, and strategically create opportunities to use them.
Yeah I want to avoid Unity for that very reason. I'd much prefer open source if I can. I've found that Godot has a lot of accessible documentation.
I'll echo what Akir said, though I will riff on it a bit. Disclaimer: I'm not a game developer or professional programmer, I've just been learning Godot in the background for around eight or nine years now.
I do think I'd recommend tempering your expectations (beyond what you think is necessary); in my experience, games are almost always more complex to implement than we expect, RPGs (even RPG-lites) most of all. Like, I've played plenty of RPGs, so I know that "loot, character XP leveling & attributes, magic & spells, items, gear, and upgrading spells, weapons and gear" sounds like it's somewhat stripped down from what a typical RPG offers, but having tinkered around with creating many of the types of systems you mention, I've found that they can be deceptively tricky. Those things and the interactions between them are a big part of what makes any RPG complex (I would guess the remainder is mostly dialogue and quest management). If you've never done any of that before, it can be a lot to handle.
That said--
It doesn't sound like this will be a pillar of your financial security or anything, so you're not taking a risk by doing things in a way that is less efficient or more challenging than it needs to be. If that's what you're interested in, then there's a good chance that working on it is how you'll learn best. I would just advise that you go in with the attitude that it's okay if, months or a year from now, you haven't made tangible progress on this specific project. As someone who is no stranger to transient fixations, I've started loads of projects over the time that I've been working with Godot, and I've finished like four of them haha. But I'm okay with that for three reasons: (a) I'm not financially dependent on it, (b) I learned a huge amount from every project anyway, and (c) I'm having a blast.
So if you're not bothered by the thought of never even making it to Early Access, I say go for it! The worst that can happen is that you learn a ton about something you think is cool and don't publish a game.
Resource recommendations (mostly Godot)
The documentation is generally pretty awesome for the fundamentals of most things. You'll definitely find areas in which it's lacking when you start digging deeper, but it should be excellent for most things at the beginning.
GDQuest is pretty great. I used to not love their teaching or coding style, but that was partially because I just didn't understand it well enough yet, and they have created a lot of excellent learning materials since the time when I formed that opinion. I also very (very) briefly did some work for them and I get the impression that they're good people. Their site's overall aesthetic is not really my taste, but it doesn't take away from the education they provide.
Godotneers (YouTube channel) - So so so good. Cannot recommend enough. As a hobbyist, I obviously can't confirm this, but I get the impression this channel is run by someone with real experience in how to do this stuff correctly, as opposed to the many (well-meaning and genuinely enjoyable) "how to be a gamedev" channels out there. The videos are long, but the explanations are generally very good and they concepts he covers are almost always powerful things that will serve you well in loads of different ways. I don't think I would start here though, since these are more deep-dives on specific topics/techniques.
Game Programming Patterns (web book) - This was what helped me start understanding programming beyond just writing methods and scripts and realizing what software engineering actually means. Knowing how to put systems together and having tools in your toolbelt with which to construct them is crucial for games.
The off-brand forums (https://godotforums.org/) - Not actually affiliated with the Godot project/Foundation, but generally still pretty decent
Stackoverflow, of course
Don't be afraid to dive into GitHub issues if that's where the answers seem to be. The project leads are very active and often have good insights to offer.
If you're feeling especially brave, the engine source can sometimes be helpful to see too, if you run into a particularly confusing bug and no other results are turning up.
Reddit is actually not awful, though it's more hit-or-miss than the others usually are
The documentation has a "community notes" feature which sometimes has helpful suggestions in it. Basically, anyone can comment on any page of the docs to remark on things they think add to the information it contains. Sometimes you get confused people using this as a support portal (which it explicitly says not to do lol), but usually these are a good source of thoughtful recommendations.
Misc
Be careful using LLMs with GDScript/Godot. I've never used a paid one, so I can't speak to the level of quality there, but the ones I use as a fallback when searching fails me (the free models available on duck.ai) are... okay. They usually get GDScript syntax pretty much right and their algorithm suggestions are fairly decent too, but the problem is that, often, the crucial element their solution revolves around will be entirely hallucinated. They (unsurprisingly) regularly just invent whole classes that don't exist. But, critically, those classes look extremely plausible, which means this will waste you TONS of time if you don't know the part of the engine you're working with well enough to immediately spot when the LLMs do this. Honestly, I would not use them for learning fundamentals, or even for a while after that, if ever.
Also, if you want someone to rubber-duck with or even just chat about Godot, let me know! I'm happy to do anything related to this stuff.
Haha Yes, I should definitely temper my expectations. Typically I throw myself at projects aiming at the stars so I can reach the moon, or at least the horizon.
Luckily I have been writing extensive notes on the game mechanics and how they all play into each other, including how all the leveling will work with damage and tile spawn rates. The trick will be getting it off of paper and into a practical product.
And you're absolutely right, the worst thing that can happen is that I learn something! It'll be a good dopamine source for a while at least.
The trick will be getting it off of paper and into a practical product.
Ha, I guess I didn't quite say it specifically, but this is 100% what I was getting at. That is always the trick! The challenge (or devil, if you will) is in the details and execution.
You sais pretty much everything I wanted to say to @CrypticCuriosity629 going into the thread, good stuff! I'll just add one reference, then: Godot's community Discord server. I hang out there a lot and it's a really great place for learning, where the help channels are always going fast and people are nice and helpful. Discord does have the problem of not allowing web indexing but sometimes, you need to ask someone directly about your issue and I find it's a great place to do so.
Ah, I meant to mention the community "cafe" server but forgot after it wouldn't allow me to share an invite ("maximum number of invites reached" apparently?). Assuming OP can still get in, I agree it's a great resource. Thanks for bringing it up!
I'd like to recommend David Buckley's courses, but the full pack I got from humble is listed at $1500 so no. There is this free course that covers the Godot basics from him, I like him as an instructor and I'd recommend sticking with as few "instructors"/tutorial providers as you can since they'll be more consistent.
I'm actually working on a match 3 mini project in Godot right now, I'm almost wrapped up. It is my first project from scratch by myself so it's been messy. Feel free to bounce me ideas/questions as you do yours.
Akir's advice on separating your game into its base components then working on those is great.
And stick with 2D nodes over UI for the blocks and grid.
Thank you! I'll look into those courses! I like the idea of doing a course. $1500's a bit steep for me now, but who knows, I'm just glad to know it's an option.
And cool! What a coincidence. Yeah for sure, if I any questions I'll for sure ask!
Oh yeah the 1500 is quite silly, I paid $25 for it. I don't know your finances but there's enough quality free resources I don't think I'd spend much more than that. Just save it for the Steam $100 fee.
But I'm not sure where to start. I'm looking into Godot because it's free and open source and has a lot of community resources, but also wanted to see if anyone had any ideas here.
Godot is a world-class engine. So much good stuff has been coming out on it. @all_summer_beauty's links seem solid. I've done some dev in it, mostly prototyping on like 3.4 to make a Zelda-style movement demo and it's probably the best thing going for free. It should be able to handle the sort of context switching you want like any other engine as well. Just check out Casette Beasts for a commercial, large-scale, multi-modal offering. Even Sega used it for a remaster of Sonic Colors. It's hitting the mainstream as a respectable engine similarly to how Blender is finally getting its flowers.
I enjoyed the GameDev Tavern's video tutorials series on building two fairly straightforward, but different games. Each part of the series builds on the previous in a natural progression. I think they made a bunch of the resources available, but I used other ones just to get a better grip on the process. It's too easy for me to otherwise just end up in copy paste land (and then I don't really learn).
I'm learning gamedev and I've been using Godot, I love how it gets updated so frequently and the community's so friendly and helpful (Godot official forums, subreddit).
I'm going to echo most of the other comments in this thread and say: start small. Something as ambitious as an RPG as your first project might result in unforeseen complications piling up and getting discouraged by a lack of progress, and I know how lethal that can be to a project especially when ADHD gets into the picture from first hand experience.
This doesn't necessarily mean don't start work on your project, but I would advise also setting some simpler challenges to yourself that you can complete in a short timeframe to gain momentum as you get the hang of software development and the other aspects of game design and hopefully gain more knowledge through practice that you can apply to your longer term project.
One tool I've picked up that is very useful for this is PICO-8, an hybrid of an IDE and a fantasy retro game console inspired by 80s era hardware. It's based on Lua, and lets you build and play games while setting arbitrary limitations (128x128 screen, very limited color palette, size limit for the codebase of any given "cart", 8-bit era style audio...) to force you to keep things short and simple. It's very handy to test smaller ideas and get a working prototype for a concept without having to whip out a full-fledged game engine.
While the native executable is paid software, you can try it out for free using the education edition which runs in the browser. You can also browse the PICO-8 website and run games made for it on your browser (there's also a way to do it within the native application called SPLORE, though it's not available in the education edition). Fun fact: Celeste started out on PICO-8!
There are many resources dedicated to PICO-8 (in fact the main website has a resources section including a user manual). Among those, I would recommend SpaceCat and Lazy Devs who both provide game dev tutorials using PICO-8 on their channel.
Akir | 22 hours ago
If you are new to gamedev, I wouldn’t recommend trying to make an RPG as your first game. They tend to be kind of like making multiple games in one; you have to make a game that is the map screen, a game that is the battle system, and a tiny game that is all the menus you will have to build. It’s fairly broad in scope so you’ll be stuck on what to do because there will be so many things to do.
What I would suggest is to try to build the simplest part of your game you can make standalone first. In your case, try to make the match three part. That also happens to be the keystone of your game since it’s the battle system so you can prototype it and see if you can make it fun to start with. Once you have that pretty nailed down you can start to implement more and more RPG elements.
I’m partial to the LÖVE framework since I’ve been using it for a while and it’s pretty easy since lua is a simple language. Doing this is going to be very programming-forward since you’ll be building your game engine. If that doesn’t sound good to you start learning Godot. Unity is probably easier to learn and use if you are ok with proprietary software with legal encumbrances (they are the guys who were trying to get studios to pay more retroactively).
Bwerf | 22 hours ago
Very good advice imho. I want to echo that an rpc is usually a lot of work. Both like what Akir is saying about building many games in one, but also when it comes to content. There's usually a lot of dialog, loads of art for every location, many characters that need art, animations, lots of world design, etc... I also suggest doing what Akir is already saying, implement the match three to a degree that you're happy with it, polish it as much as you have the energy for, you're going to learn a lot in that process. And then start adding onto that.
About the game idea itself, I think it can work, this is all about execution and balancing the different aspects against each other.
[OP] CrypticCuriosity629 | 21 hours ago
I do want to stress that it wouldn't be a deep RPG, so no dialogue, navigable maps, no complex inventories or in depth world design, not even a controllable character outside of tapping around the inside the saferoom for them to walk around to where you tapped. Also probably not a lot of characters outside of the player character and the enemies.
The RPG elements I'd be borrowing are more the loot, character XP leveling & attributes, magic & spells, items, gear, and upgrading spells, weapons and gear. But within a limited framework.
Like the idea is that the player character selects their weapons/spells and chooses 2 items(potions, smoke bombs, etc) to take with them on the run, then when outside the saferoom, PC auto runs along a 2D corridor until they get to an enemy, combat is initiated, and after combat is complete character continues to run. Match 3 can be used outside of combat to heal, replenish mana, or temporarily boost stats between enemy encounters depending on items selected at the saferoom, rinse & repeat until next saferoom. Enemies get harder, have environmental effects, etc.
Bwerf | 21 hours ago
Sounds good, it feels like you have thought this through. Looking forward to seeing the end result.
[OP] CrypticCuriosity629 | 22 hours ago
Thanks for the advice!
I pick up a lot of hobbies, and it's not that I want to develop a game, I want to develop this game. Haha
So it's not a full RPG, it's a relatively light RPG. So there's no map, at least not one you can navigate, you won't control the character movement, there isn't any extensive menus, there's no inventory management, no complex dialogues or quests, the combat is entirely dictated by matching the correct match-3 tiles, so combat isn't the same as typical RPGs.
I guess, at least in my head, I'm having a difficulty separating the two systems the way I want them to work together. But I mean yes, nailing the match-3 mechanics is definitely the first on the todo list.
But I am planning the RPG elements to be very basic, so not a deep RPG, but deep enough to mesh with the match-3.
Yeah I want to avoid Unity for that very reason. I'd much prefer open source if I can. I've found that Godot has a lot of accessible documentation.
all_summer_beauty | 20 hours ago
I'll echo what Akir said, though I will riff on it a bit. Disclaimer: I'm not a game developer or professional programmer, I've just been learning Godot in the background for around eight or nine years now.
I do think I'd recommend tempering your expectations (beyond what you think is necessary); in my experience, games are almost always more complex to implement than we expect, RPGs (even RPG-lites) most of all. Like, I've played plenty of RPGs, so I know that "loot, character XP leveling & attributes, magic & spells, items, gear, and upgrading spells, weapons and gear" sounds like it's somewhat stripped down from what a typical RPG offers, but having tinkered around with creating many of the types of systems you mention, I've found that they can be deceptively tricky. Those things and the interactions between them are a big part of what makes any RPG complex (I would guess the remainder is mostly dialogue and quest management). If you've never done any of that before, it can be a lot to handle.
That said--
It doesn't sound like this will be a pillar of your financial security or anything, so you're not taking a risk by doing things in a way that is less efficient or more challenging than it needs to be. If that's what you're interested in, then there's a good chance that working on it is how you'll learn best. I would just advise that you go in with the attitude that it's okay if, months or a year from now, you haven't made tangible progress on this specific project. As someone who is no stranger to transient fixations, I've started loads of projects over the time that I've been working with Godot, and I've finished like four of them haha. But I'm okay with that for three reasons: (a) I'm not financially dependent on it, (b) I learned a huge amount from every project anyway, and (c) I'm having a blast.
So if you're not bothered by the thought of never even making it to Early Access, I say go for it! The worst that can happen is that you learn a ton about something you think is cool and don't publish a game.
Resource recommendations (mostly Godot)
Discord Links
Quality sources to watch for when searching for answers
Misc
Also, if you want someone to rubber-duck with or even just chat about Godot, let me know! I'm happy to do anything related to this stuff.
[OP] CrypticCuriosity629 | 19 hours ago
Haha Yes, I should definitely temper my expectations. Typically I throw myself at projects aiming at the stars so I can reach the moon, or at least the horizon.
Luckily I have been writing extensive notes on the game mechanics and how they all play into each other, including how all the leveling will work with damage and tile spawn rates. The trick will be getting it off of paper and into a practical product.
And you're absolutely right, the worst thing that can happen is that I learn something! It'll be a good dopamine source for a while at least.
Thank you for the resource recommendations!
all_summer_beauty | 15 hours ago
No problem! I hope they're helpful!
Ha, I guess I didn't quite say it specifically, but this is 100% what I was getting at. That is always the trick! The challenge (or devil, if you will) is in the details and execution.
Good luck! And have fun! :)
Trobador | 11 hours ago
You sais pretty much everything I wanted to say to @CrypticCuriosity629 going into the thread, good stuff! I'll just add one reference, then: Godot's community Discord server. I hang out there a lot and it's a really great place for learning, where the help channels are always going fast and people are nice and helpful. Discord does have the problem of not allowing web indexing but sometimes, you need to ask someone directly about your issue and I find it's a great place to do so.
I'd also be happy to talk and rubber duck for OP!
all_summer_beauty | 7 hours ago
Ah, I meant to mention the community "cafe" server but forgot after it wouldn't allow me to share an invite ("maximum number of invites reached" apparently?). Assuming OP can still get in, I agree it's a great resource. Thanks for bringing it up!
Carrow | 20 hours ago
I'd like to recommend David Buckley's courses, but the full pack I got from humble is listed at $1500 so no. There is this free course that covers the Godot basics from him, I like him as an instructor and I'd recommend sticking with as few "instructors"/tutorial providers as you can since they'll be more consistent.
https://academy.zenva.com/product/godot-101-game-engine-foundations/
I'm actually working on a match 3 mini project in Godot right now, I'm almost wrapped up. It is my first project from scratch by myself so it's been messy. Feel free to bounce me ideas/questions as you do yours.
Akir's advice on separating your game into its base components then working on those is great.
And stick with 2D nodes over UI for the blocks and grid.
[OP] CrypticCuriosity629 | 20 hours ago
Thank you! I'll look into those courses! I like the idea of doing a course. $1500's a bit steep for me now, but who knows, I'm just glad to know it's an option.
And cool! What a coincidence. Yeah for sure, if I any questions I'll for sure ask!
Carrow | 19 hours ago
Oh yeah the 1500 is quite silly, I paid $25 for it. I don't know your finances but there's enough quality free resources I don't think I'd spend much more than that. Just save it for the Steam $100 fee.
knocklessmonster | 13 hours ago
Godot is a world-class engine. So much good stuff has been coming out on it. @all_summer_beauty's links seem solid. I've done some dev in it, mostly prototyping on like 3.4 to make a Zelda-style movement demo and it's probably the best thing going for free. It should be able to handle the sort of context switching you want like any other engine as well. Just check out Casette Beasts for a commercial, large-scale, multi-modal offering. Even Sega used it for a remaster of Sonic Colors. It's hitting the mainstream as a respectable engine similarly to how Blender is finally getting its flowers.
archevel | 14 hours ago
I enjoyed the GameDev Tavern's video tutorials series on building two fairly straightforward, but different games. Each part of the series builds on the previous in a natural progression. I think they made a bunch of the resources available, but I used other ones just to get a better grip on the process. It's too easy for me to otherwise just end up in copy paste land (and then I don't really learn).
feanne | 6 hours ago
Excited for you!
I'm learning gamedev and I've been using Godot, I love how it gets updated so frequently and the community's so friendly and helpful (Godot official forums, subreddit).
Heartbeast on youtube has a tutorial series for making an RPG in Godot. I think he's very patient and approachable with how he explains things.
Queble on youtube has some great intermediate/advanced Godot tips.
I have a small list of mostly free gamedev tools and resources including free graphic software, game assets, etc, in case this is helpful.
Hope you have lots of fun making your game!
onceuponaban | 8 minutes ago
I'm going to echo most of the other comments in this thread and say: start small. Something as ambitious as an RPG as your first project might result in unforeseen complications piling up and getting discouraged by a lack of progress, and I know how lethal that can be to a project especially when ADHD gets into the picture from first hand experience.
This doesn't necessarily mean don't start work on your project, but I would advise also setting some simpler challenges to yourself that you can complete in a short timeframe to gain momentum as you get the hang of software development and the other aspects of game design and hopefully gain more knowledge through practice that you can apply to your longer term project.
One tool I've picked up that is very useful for this is PICO-8, an hybrid of an IDE and a fantasy retro game console inspired by 80s era hardware. It's based on Lua, and lets you build and play games while setting arbitrary limitations (128x128 screen, very limited color palette, size limit for the codebase of any given "cart", 8-bit era style audio...) to force you to keep things short and simple. It's very handy to test smaller ideas and get a working prototype for a concept without having to whip out a full-fledged game engine.
While the native executable is paid software, you can try it out for free using the education edition which runs in the browser. You can also browse the PICO-8 website and run games made for it on your browser (there's also a way to do it within the native application called SPLORE, though it's not available in the education edition). Fun fact: Celeste started out on PICO-8!
There are many resources dedicated to PICO-8 (in fact the main website has a resources section including a user manual). Among those, I would recommend SpaceCat and Lazy Devs who both provide game dev tutorials using PICO-8 on their channel.