I can’t remember if I saw someone mention here on or some other site that they developed the different parts of their game as plug-ins, so that it’s easier to manage and test in godot.
Basically, if every thing I feel need to separate out and create a new project for to be able to test in isolation (in order to create a re-producible example for bug tracing) could then be re-imported into the main project as a plug-in, I wonder if my dev life would be easier?
Of course, things like an inventory system plug-in would perhaps need the menu system plug-in and so on…
…I don’t know since I’ve lost track of that discussion. Anyone written any blog articles about this approach?
Just code first. Then when you see yourself duplicating the same thing over and over, then make a common scene or enemy from the code that’s duplicated.
Edit:Anyway, u can just paste the components over if it’s your personal project. You aren’t building like Hibernate or Apache Tomcat for everyone. For yourself, u can just keep it in your repo
That may have been me. I don’t do all my game development that way, but I do a lot of it that way. I have a Game Template Plugin that I use when I start a new game that contains the 6 most common ones. One of the reasons you don’t see more of these is the Godot Asset Lib doesn’t support dependencies.
Game Template Plugin
This has 2D and 3D example projects that I start from. It also uses 6 other plugins to make it work. They can also all be used separately if a project doesn’t need all the functionality.
Controller - Tracks whether they player is using a key/board/mouse or controller. Has a function Controller.get_action_icon() that returns a Texture2D for any action you pass it. It supports all the major controllers, mouse and keyboard. It also handles mouse and controller input so that you can use them the for 3D look in your code (this can be toggled on and off). All the icons are fully configurable. It also has functionality (and optional UI) for for keybing (remapping actions) for the end user of your game.
Disk (Save/Load) - Handles saving and loading game settings and nodes to disk with a few simple commands. Also has a toggleable save on exit feature.
Display - Handles things like full screen, screen resolution, multiple monitor support, etc. Also comes with a UI (that is not yet optional but will be at some point).
Sound - Handles volume control across the project for various buses (if they exist) with an UI (which again will be optional in the future). It also stores commonly used sounds for use across the project in a central location, like the button press sound. (If both the Sound and UI plugins are present, every button press in the UI will automatically be hooked up.) It also contains a bunch of music functions in the Music autoload - including maintaining a main game audio player and pause menu audio player, and functionality for fading music in and out.
State Machine - The workhorse of my games, and the most popular plugin I’ve created. It is a pull-based state machine. Which means the states decide when to switch. I use it for my main game, levels that have multiple states, and characters (players, NPCs, enemies). They can also be added and removed from the machine at runtime without affecting its performance, making it easy to add new features like double-jump, etc.
User Interface - Has a Screen base class that allows you to seamlessly open/close screens and move between them. Also has a SplashScreen class for displaying splash screens at the start of your game.
General Plugins
A have a few other general plugins that are optional. I really only use the Localization one these days.
Localization - Leverages Godot’s built-in translation functionality, and also creates an OptionButton you can drop into your projects that detects the languages you have translations for, and adds an option for each one. Has flags for every country that display in the button.
Keyboard Keys - Displays an entire US keyboard on screen and shows when any key is pressed.
Interaction - A component to add to items to make them interactable. Handles highlight, mouseover and input.
2D Plugins
Collison Sprite 2D - A custom CollisionSprite2D class that creates collision polygons when the game runs that match the visible pixels in a 2D texture.
Camera 2D - A bunch of components that can be added to a Camera2D as nodes and add in zoom and pan functionality for keyboard/mouse, controller, and touch. Also a component allows you to limit a camera to a TileMapLayer, and another that does screen and controller shake.
Curved Terrain 2D - Adds a new node that gives you the ability to create curved terrain with square tile map images.
Camera 3D - Handles multiple cameras and switching between them. Supports 1st-persona dn multiple 3rd-person camera styles.
Character 3D - A character controller for 3D characters. (Being revamped right now to be easier to use.)
In Development
These are no publicly available yet.
Character 2D - A character controller for 2D characters.
Curved Text - Node2D and Control nodes that both display curved text along a line you draw.
Multiplayer - Early development, but helpers to make creating a multiplayer game easier without being heavy like most plugins like this.
Text to Speech - Plugin that leverages the Godot text-to-speech system.
Conclusion
I use plugins because I don’t like to have to code things more than twice. As I refactor, I tend to pull things into addons. Because I’ve done a lot of game jams, these have evolved a lot over time. If I had just been doing a single game, these wouldn’t be nearly as helpful. I’ve made them all open source because I’m hoping others can benefit from my work. Which is the point of FOSS.
I kinda am. I’ve had community engagement on my State Machine plugin - even a few PRs. I don’t know where they will go, but the point for me is to make tools that work for me, and let others use them if they wish.
In the mean time, I do add them to my projects quite frequently - including the ones where I’m being contracted and paid to work on. Which means les time repeating work.
