Any beginners advice or resources on developing a 2D RPG/Puzzle video game?
Hey guys, I hope this is the right place to post.
So my adhd hyperfixation has recently shifted towards an idea for a game and I want to indulge my ADHD by learning all I can about game development to see if I can achieve this idea to the point that maybe I can put it in "Early Access" to fund even more resources on it.
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.
I have some coding experience, a lot of technical experience and pick things up extremely quickly.
The basic idea is that it's a 2D Sidescrolling RPG, but with Match-3 "Candy Crush"-esque mechanics for battles and fighting.
Extra details
If you've played "You Must Build A Boat" or "10000000", it's a LOT kind of like that, in fact those games kind of inspired me, but more refined with a lot more in depth RPG elements and it's a bit more forgiving focusing on keeping a "flow" going, since one of my biggest pet peeves is YMBAB's RNG being very unforgiving and you'll randomly just sit there staring at the board with no moves until you die.So the systems/mechanics I'd need to combine to work together are the following:
- A Match-3 type board where you match tiles, make special tiles by combining 4 or more tiles, all the features of a typical match-3 type game, just tied to outcomes outside of the board-interface.
- An RPG element, with character attributes, leveling, items, spells, weapons, gear, potions, etc. These elements effect what tiles are on the board during gameplay, effect the chances of certain tiles, and effect health, speed, mana, or grants special in-game abilities like "Precognition"(gives a hint for a move), or "Scroll of Revival"(You can continue without starting over), etc. Attributes also effect things like tile chances, so a higher strength will get you more combat/physical tiles, or a high intelligence will get you more magic tiles.
- Visual Elements include an auto-running sidescrolling viewport while Dungeon Running. Character auto-runs until encountering enemies, running is not controlled by player. Match-3 board will be beneath that. Time between enemy encounters can be used to clean up the board and match unneccesary tiles, make special moves to line up for next battle, or to replenish health.
- During Battles, it'd be an over-the-shoulder battle view, similar to Pokemon style battles. Character will have health, enemy will attack character at regular intervals, player will have to balance matching combat/weapon tiles to attack enemy, and matching health/mana potion tiles to replenish health or mana(if they have potions equipped). Enemy can cause environmental effects like poison(some tiles will be poisoned so you lose health if matching them), or being frozen with ice(You need to break tiles next to the ice tiles to break them), or confusion(switches the colors of tiles). Will be block/parry mechanics, occassionally for a few seconds before the enemy strikes, you're required to match a designated tile to either block or parry that attack.
- In a saferoom it'd be like an isometric kind of "inside a building" format like in Pokemon, just more detailed. I'd like to have saferoom customization and the ability to upgrade your character or gear too.
Anyways, I'd love any advice or resources. Or if you'd like to help out or discuss the game idea more I'm up for that too.
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.
Sounds good, it feels like you have thought this through. Looking forward to seeing the end result.
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.
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.
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!
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! :)
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!
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.
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.
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.
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).
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!
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 for 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 and sprite space, 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.