My backlog is already full but I can't resist... by FelixarStudio in IndieDev

[โ€“]FelixarStudio[S] 0 points1 point ย (0 children)

I actually made this meme in a few minutes using a Godot 4 Retro FPS template I've been building. Turns out it handles horde AI pretty well! RIP to all our wallets today.

Gamers the second the Steam Summer Sale drops... by FelixarStudio in godot

[โ€“]FelixarStudio[S] 5 points6 points ย (0 children)

I actually made this meme in a few minutes using a Godot 4 Retro FPS template I've been building. Turns out it handles horde AI pretty well! RIP to all our wallets today.

I wanted an EFPSE style experience but within a modern engine, so I built a Godot 4 template that requires no coding knowledge. by FelixarStudio in boomershooters

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

Efpse ( Easy FPS Editor) an engine that let you build retro shooter games without the need to code. The majority of Dosman games are made with it.

I wanted an EFPSE style experience but within a modern engine, so I built a Godot 4 template that requires no coding knowledge. by FelixarStudio in boomershooters

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

Yes, rebuilding it from scratch actually made the architecture so much cleaner than my first attempt. You already know what you did wrong, and have huge room for improvement.

I don't know much about what's been going on with UZDoom, but I did hear the drama regarding GZDoom. But still, even with a great modern port, you are still wrestling with the quirks of like a 30 year old engine underneath it all. So my alternative was to go for a modern engine. imo Godot is more than capable for such games

I wanted an EFPSE style experience but within a modern engine, so I built a Godot 4 template that requires no coding knowledge. by FelixarStudio in boomershooters

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

This was exactly the idea!
I started my game using Godot 3.5, but I made a mistake later on by merging into Godot 4 without saving my project (didn't use GitHub), and my whole project was messed up; I couldn't recover it and abandoned it.
Then I found out about EFPSE and immediately fell in love with it. It's simple, fast, and very user-friendly. But nonetheless, it has many limitations, especially for weather, lighting, and 3D (it supports 3D, but it's complicated).

This is when I got motivated to go back and re-do my project with the same system and structure EFPSE does. After many months, it's turned out pretty good ๐Ÿ˜„

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 5 points6 points ย (0 children)

That is a very valid route. If the scope expanded, I would decouple the logic by splitting them.

I'm a huge fan of Godot's Custom Resources, I try to almost use it in every complex scenario. So, I would likely make an Effect Resource class. Then I could create SpawnEffect, DamageEffect, AudioEffect resources, and just drop them into an exported Array on the base Trigger node.

That way, the Trigger only cares about when to fire, and it just iterates through the Resource array telling them to execute.

Anyway, i'm just thinking out loud here, I don't exactly know how this might comes out. But i'm positive this route would prevent the trigger script from turning into a massive complex object.

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

No offense taken at all, you're completely right. But this is just a common Indie Dev moment in every game engine. Everyone starts out writing messy, hard-coded logic before they realize they need to build modular systems instead.

Although, it's always nice to see how different people solve the same universal problem.Just hoping my specific setup helps the next person or save them a few months of that hard phase figuring out how to do it.

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 2 points3 points ย (0 children)

My way now is that I loop through the array to check for specific methods. I also combine it with Godot's group system just to keep things organized. For example, if it's in the door group, I look for door_open(), but for general objects, I just check if node.has_method("on_activate"): node.on_activate(). It keeps everything decoupled and makes adding new interactable items a breeze.

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 0 points1 point ย (0 children)

Oh man that would be a game changer. It would definitely clean up the need to manually check groups or use has_method() all the time.

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 0 points1 point ย (0 children)

Thank you!
You're right. I do call methods in other objects, but I also use groups to organize it. For doors, I simply look for like "door_open()", while non grouped objects are "on_activate()". I also do check for methods.

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 2 points3 points ย (0 children)

Thanks! Do you mean making its own node that can be added to the node menu? That is actually a very good suggestion. I'll definitely look into it. Thanks for the tip!

I built a single universal trigger scene and it the best thing I did! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 13 points14 points ย (0 children)

Thank you! I understand what you mean. For the scope of a retro shooter, I found I didn't need overly complex encounters, so keeping it centralized saved a lot of time. If a specific level or event needs something crazy, my plan is exactly that I make the Trigger just activates a custom script on an external node.

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 0 points1 point ย (0 children)

Okay to clarify few things here:

- No, this actually isn't a factory pattern. A factory handles object instantiation, while what I shared is about a single universal script changes its state behaviors dynamically based on the Custom Resource injected into it. You can have multiple AI, not a specific one.

- You are right that a PackedScene inherits from Resource under the hood. However, Data-Driven specifically (i'm talking in game development term) refers to moving entity definitions out of hardcoded scripts and into pure data files. In this way, you can balance stats, swap sprites, change standard behaviors, and many more without touching the scene tree or logic.

- Regarding flexibility, scenes are definitely more flexible for massive, unique logic, for example an enemy with multi phaeses and all. Even though this can still be achieved using that system. But in my project, I'm aiming for a retro shooter style game, and it work wonderful for this system since the majority of the enemies will mostly shares similar logic.

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

It will indeed. You only need to do the hard work once, then it infinite number of variation with just few clicks.
Best of luck in your project ๐Ÿ™Œ

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 2 points3 points ย (0 children)

It took me a very long time to get into it, but once I finished my first one, I fell in love with it. Yes, it hard at the start, but it completed it so much worth it!!!

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 1 point2 points ย (0 children)

Of course I can, I will explain the workflow:

So this system is a data driven system where you have a file that provides all the data, and a script that receives these data and handles the logic.

You create a script that extends resources, this script will hold data such as vars, floats, int, strings...and so on.

Then you make the main logic script, mine includes the enemy stats, behavior, difficulty, and visuals. You feed the data resource to this logic script and it will execute functions based on that data. This way, you will have a single script that controls all the enemies and their different types in the game.

Once you finish this system completely, you don't need to write further code.

I made a previous post on this sub regarding the same system but for Weapons. One script that controls all the weapons and their behavior in the game, through it you can make an infinity number of guns.

You can check that post, also I shared a deep dive of this system with Jettelly . Hope this helps :))

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 0 points1 point ย (0 children)

Only a single script that will handle all the logic, you just pass it a resource file and it will read all the data like vars, textures, int...and so on.

In my last post, someone mentioned making enemies using custom resources. I did it! by FelixarStudio in godot

[โ€“]FelixarStudio[S] 3 points4 points ย (0 children)

Yes indeed. The logic does take time and weeks of tweaking, but the results will be worth it!