How hard is it to make a roguelike / JRPG with no programming experience in this engine?

[☾⎛sιтєʀ⎞☽]

If I wanted to make a very complex roguelike / roguelite and/or JRPG such as one like ADOM or Elona+, how hard would it be with no programming experience? What language would I have to learn? Would Python / Visual Programming be sufficient?

I heard there was a big community behind this engine. Are there any good roguelike / RPG scripts the community has made?

[Sersch]

In general, if you want to make something very complex you need experience to do it, or else you'll inevitably struggle a lot. I suggest you set simple goals first (like a simple room with four walls and a 2D box character that can walk around and collide with them). After a while, you'll get used to how things work.

To create a game you have two options: either write the code or use visual scripting. You are coding in both cases, it's just that visual scripting looks more friendly at first. But under the hood the outcome is the same. Godot's own language is called GDScript. You only need to learn this language if you want to work with Godot. You can write in other languages like C#, but GDScript was made just for Godot; it's very easy to read and understand after a short time.

I suggest you take a look at writing real code first. If you are really struggeling and can't get into it, try visual scripting.

When I started with Godot I learned a lot in the official docs. Start here https://docs.godotengine.org/en/3.1/getting_started/step_by_step/index.html I suggest reading everything in order. In the "Your First Game" chapter you'll learn to code a simple game step by step.

[Baroon Valm]

GDScript is a lot like python.. its sort of like python-lua mix, but visual script is also very much usable (there aren't any limits to it's power compared to GDScript for example, just takes some getting used to some things)

[☾⎛sιтєʀ⎞☽]

Originally posted by Sersch:

In general, if you want to make something very complex you need experience to do it, or else you'll inevitably struggle a lot. I suggest you set simple goals first (like a simple room with four walls and a 2D box character that can walk around and collide with them). After a while, you'll get used to how things work.

To create a game you have two options: either write the code or use visual scripting. You are coding in both cases, it's just that visual scripting looks more friendly at first. But under the hood the outcome is the same. Godot's own language is called GDScript. You only need to learn this language if you want to work with Godot. You can write in other languages like C#, but GDScript was made just for Godot; it's very easy to read and understand after a short time.

I suggest you take a look at writing real code first. If you are really struggeling and can't get into it, try visual scripting.

When I started with Godot I learned a lot in the official docs. Start here https://docs.godotengine.org/en/3.1/getting_started/step_by_step/index.html I suggest reading everything in order. In the "Your First Game" chapter you'll learn to code a simple game step by step.

Thanks for the advice. I once tried learning Ruby and looked at even harder programming languages. It made me feel that shooting myself would be better lmao.

[Sersch]

I can relate to that :D I think if you are already a bit familiar with the basic concepts of programming like variables, classes and so on, you'll be able to quickly apply that knowledge to Godot. If you don't know the basics yet, I think you've picked a great engine for learning them.

I started coding with Blueprints in Unreal, never wrote real code before. After I understood how coding works in general (Blueprints are code too, after all. It's just represented with pretty buttons) I tried C# in Unity and was surprised how fast I could convert the knowledge from a visual interface to real code. After that I switched to Godot and everything felt familiar pretty fast.

Visual scripting really helped me a lot in the beginning. I don't know if I'd have ever picked up coding if I couldn't have learned it visually first. So if code intimidates you too much, go for visual scripting, there's no shame in that. It's just more convoluted and harder to read once your game becomes more complex. I think as soon as it starts to annoy you, you'll gradually and naturally switch to code.

Here are some YouTube channels that will help you a lot with Godot:

https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ
https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg
https://www.youtube.com/user/uheartbeast

Nevertheless I'd stick to the official documentation at first, because you can overwhelm yourself quite easily with so much input. And the docs are really good :)

[☾⎛sιтєʀ⎞☽]

Originally posted by Sersch:

I can relate to that :D I think if you are already a bit familiar with the basic concepts of programming like variables, classes and so on, you'll be able to quickly apply that knowledge to Godot. If you don't know the basics yet, I think you've picked a great engine for learning them.

I started coding with Blueprints in Unreal, never wrote real code before. After I understood how coding works in general (Blueprints are code too, after all. It's just represented with pretty buttons) I tried C# in Unity and was surprised how fast I could convert the knowledge from a visual interface to real code. After that I switched to Godot and everything felt familiar pretty fast.

Visual scripting really helped me a lot in the beginning. I don't know if I'd have ever picked up coding if I couldn't have learned it visually first. So if code intimidates you too much, go for visual scripting, there's no shame in that. It's just more convoluted and harder to read once your game becomes more complex. I think as soon as it starts to annoy you, you'll gradually and naturally switch to code.

Here are some YouTube channels that will help you a lot with Godot:

https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ
https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg
https://www.youtube.com/user/uheartbeast

Nevertheless I'd stick to the official documentation at first, because you can overwhelm yourself quite easily with so much input. And the docs are really good :)

Thanks. I might try out visual coding as it looks a bit easier than typing and looking at large blocks of code for hours. I'm pretty good with micro management games with complex interfaces too and linking things together to make even more complex stuff (RimWorld, Dwarf Fortress, etc). The visual interface seems similar except you use nodes and variables instead of in-game factories or whatnot.

[Sersch]

I think playing such games can really help.

I'm no advanced programmer by any means, I'd say I'm somewhere between a beginner and having some good basic understanding, but here's what helped me so far:

1. Coding often times is about automating and reusing things. If you ever catch yourself wanting to write a line of code twice (or in the case of visual scripting arranging a group of nodes the same way a second time) you've already found something that can be grouped and reused.

2. Before you start coding anything, write down what exactly you want to achieve. You'll most likely notice while writing it down that there are some required steps you haven't thought about before.

3. Don't use placeholder names for anything, name things correctly right away and keep the names short.

4. Create a journal where you summarize solutions for concepts you struggle with, so you can take a quick look at your journal instead of searching for that one video tutorial you can't find anymore that answered this one specific question.

5. Backup everything regularly. There's always the danger to rework a piece of code to death and end up worse than when you started. The easy way is to simply mirror your project folder to some backup location with a tool like FreeFileSync https://freefilesync.org/ If you are feeling fancy and need more control, I suggest using Git https://git-scm.com/ I like the interface called git-cola for it quite a lot https://git-cola.github.io/ Git allows you to create revisions of your project, compare files with older versions, restore older versions and so on. It's a bit weird and intimidating to use at first, but nothing one cannot learn. The big plus is that you can use it completely offline without any logins or servers (but you can if you so desire). Should you ever get to a point where you'll collaborate with other people, Git will help a lot.

6. Start with simple games. So simple you wouldn't even call them a game. Create small test projects where you just try to figure out how to code one specific feature, like for example a falling ball that bounces and destroys certain objects it touches.

7. Try to learn about the ways objects can communicate with other objects. There are lists you can store references in, collision detection, raycasts, groups you can call, signals and so on. It's always nice to know what to use in which case. Some things work better than others, depending on the situation.

8. Don't optimize too early. Not leaving a burning mess behind you is one thing, but don't try to stress yourself too much by trying to find the optimal fastest nicest solution for anything right at the start while writing the code. First make things work and see if your idea even feels good once you play it. You can refine things once you are sure you want to keep them.

9. Don't waste time by creating art, focus on the code. There a tons of free resources on the web, be it textures, 3D objects or sounds. If you are able to, you can always recreate those things later on, but first and foremost you'll want to have a game that's fun to play. It doesn't matter if it looks bad.

[☾⎛sιтєʀ⎞☽]

Great advice! Thanks a bunch!

[pikadon92]

Once you're ready to create a jrpg, you may want to look at the temples tab before starting a new project. I'm about to post one for the otherworld.

[☾⎛sιтєʀ⎞☽]

Originally posted by pikadon92:

Once you're ready to create a jrpg, you may want to look at the temples tab before starting a new project. I'm about to post one for the otherworld.

My original / dream goal was to make a JRPG roguelike as complex as Elona+. Check it out and you'll see what I mean.

[Pudding]

I want to reiterate Sersches 6th advice:

Originally posted by Sersch:

6. Start with simple games. So simple you wouldn't even call them a game. Create small test projects where you just try to figure out how to code one specific feature, like for example a falling ball that bounces and destroys certain objects it touches.

This is the biggest and best advice any budding game developer could ever receive. It is way too easy to get all wrapped up in your dream game project and end up never getting with it anywere.

Iteration is the absolute solution to this problem. No matter you start with small learning projects or want to kickstart your dream game: Start as small and simple as possible and iterate on that foundation.

Given that you want to get into roguelikes, start building a super simple empty room and just get the characters movement in order. Depending if you want the more roguelite approach of realtime or a true to the core roguelike experience using a tick based system (often referred to as Turns on UI), start with that. Use crude mspaint placeholder graphics. Smack a simple P sprite as the representative player sprite, or a mousedrawn stick figure. Visuals are not important at all at this stage.

If you already have a great pipedream going and really insist on getting that started, boil it all down into the simplest rudimentary package (see the empty room and movement system example above) - and then iterate on that, VERY slowly pushing the goalpost further and further with each iteration.

The reason why this iterative approach, especially for a budding game dev, is so paramount boils down simply to motivation. If you are hacking away at a project for months without any apparent progress, creating more problems than you solve with each day, you will really quickly drop game development alltogether as you burn out due to constant setbacks, rather than enjoy and celebrate the small successes you could possibly achieve by keeping it simple at the start.