Godot Engine – Multi-platform 2D and 3D game engine

Overview

Godot Engine

Godot Engine logo

2D and 3D cross-platform game engine

Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel. Games can be exported in one click to a number of platforms, including the major desktop platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), as well as Web-based platforms (HTML5) and consoles.

Free, open source and community-driven

Godot is completely free and open source under the very permissive MIT license. No strings attached, no royalties, nothing. The users' games are theirs, down to the last line of engine code. Godot's development is fully independent and community-driven, empowering users to help shape their engine to match their expectations. It is supported by the Software Freedom Conservancy not-for-profit.

Before being open sourced in February 2014, Godot had been developed by Juan Linietsky and Ariel Manzur (both still maintaining the project) for several years as an in-house engine, used to publish several work-for-hire titles.

Screenshot of a 3D scene in Godot Engine

Getting the engine

Binary downloads

Official binaries for the Godot editor and the export templates can be found on the homepage.

Compiling from source

See the official docs for compilation instructions for every supported platform.

Community and contributing

Godot is not only an engine but an ever-growing community of users and engine developers. The main community channels are listed on the homepage.

To get in touch with the engine developers, the best way is to join the #godotengine-devel IRC channel on Freenode.

To get started contributing to the project, see the contributing guide.

Documentation and demos

The official documentation is hosted on ReadTheDocs. It is maintained by the Godot community in its own GitHub repository.

The class reference is also accessible from the Godot editor.

The official demos are maintained in their own GitHub repository as well.

There are also a number of other learning resources provided by the community, such as text and video tutorials, demos, etc. Consult the community channels for more information.

Code Triagers Badge Translate on Weblate Total alerts on LGTM TODOs

Issues
  • Typed GDScript

    Typed GDScript

    Alright, big change coming! Let me add a bit of documentation in here.

    FAQ

    Things people asked me during the development.

    • Is it optional?

    Yes. You can use GDScript dynamically as it is now. Type hints can be used only in parts of the code.

    • Will this affect my existing code?

    It shouldn't. If it does then it's a bug. Whenever a type check is possible it will make one, but this won't affect duck-typing. Lines that are fully type-checked are indicated by a highlight in the line number. However, GDScript was very lenient about some behaviors that can be considered an error, so your script might break if it relied on those behaviors.

    • Does it improve performance?

    As it is now: no. However, this enables the possibility of future improvements in performance. A set of benchmarks are needed before we go this path.

    • Can the syntax change to be like <my favorite language>?

    No, this was discussed at length before. The syntax is similar to Python. It's made to be easy to parse without changing the GDScript syntax in itself, considering the types are optional.

    Syntax

    • Variable hint: var my_int : int
      • Optional inline initialization: var my_int : int = 42
      • Type can be omitted to be inferred from value: var my_int : = 42
    • Also for constants (but not strictly needed): const my_const : String = "Something"
    • Function declaration: func (arg1 : int, arg2 : String = "") -> float:
    • Casting: event as InputEventKey
      • It returns null if the cast is not possible.
      • It errors out if trying impossible conversion between built-in types.

    Possible types

    • Built-in variant types (int, float, Vector2, Basis, etc.).
    • Native classes from the ClassDB (Node, Resource, Sprite, AnimationPlayer.
    • Scripts of any kind, they can be preloaded into a constant, then the constant can be used as a type. includes inner classes in other scripts.
    • Named classes in the script server, as added in GDScript with the class_name keyword. Includes their inner classes too.
    • Other classes in the current script (the ones made using the class statement).

    Static checks

    As long as there any type can be fully determined, the parser will try to detect mismatches. This will be shown as an error in the editor.

    • Type mismatch when assigning to a variable.
    • Type mismatch in function arguments when making a call.
    • Missing or exceeding arguments for a function call.
    • Operation in an expression.
      • Whether the operand types are valid for the operator (e.g. can't multiply int and String).
      • What is the resulting type of operation (e.g. 2 * 2 is an int, but 2 * 2.0 is a float).
    • Whether the declared function matches the parent signature.
    • Member variable shadowing one in the same or the parent class.
    • Type mismatch between member variables and setter/getter.
    • Constants and inner classes are in the same scope: if one shadows another they error out.
    • Whether an inner class name shadows a native class from the ClassDB.
    • Non-existing identifier/function.

    Note that since this is meant to be fully optional and still compatible with duck-typing, it won't mark as an error if the member variable/method could be available in a subtype. Instead, type-safe lines will be marked with a subtle green tint in the number line. Non-safe lines will just not be marked:

    Completion

    The code completion was rewritten to make use of the type hints, and also fixed many long-standing bugs. The code is now somewhat cleaner and easier to add new features. Some improvements:

    • Better guessing based on assigned values (Fix #16257, Fix #15088).
    • Guess type of function based on the returned value.
    • Look inner classes too when guessing the type or finding candidates (Fix #1039).
    • Look into other scripts/singletons. (Fix #13951)
    • Use type-hints when they're available.
    • Better definition/documentation lookup

    Wanted feedback

    Any feedback is welcome but there's some things in particular that I want to know. In any case it's great to have sample scripts for me to test.

    • It breaks the current code of your project. This includes parser and compiler errors in general.
    • It doesn't detect a problem when it should.
    • It does detect a problem when it shouldn't.
    • It gives an error in the console saying "Parser bug".
    • It is too slow in a big file or file with lots of dependencies.

    Future

    Before anyone asks, here's a bit of ideas for the future.

    • Add types in signals, including type checks for emit_signal and connect calls.
    • Improve completion inference and better use of type hints.
    • Add warnings (#18271).
    • Homogeneous collections (like var int_array : int[] as an array of integers).
    • Optimizations for better performance.

    Closes #10630.

    feature proposal topic:gdscript 
    opened by vnen 245
  • Add a new vector-based default editor theme

    Add a new vector-based default editor theme

    A new, vector-based theme for the editor is required for good-looking hiDPI support. It should probably be drawn using Inkscape and be exportable to PNG with a script, just like the current icons.

    Related issue: UI Concept for Godot

    discussion enhancement topic:editor 
    opened by Calinou 227
  • Event Sheet style visual scripting

    Event Sheet style visual scripting

    NOTE: Here is the test repo that I added the prototype project to https://github.com/blurymind/Godot-eventSheetPrototype Everyone is free to fork or do pull requests 👍

    IDEA: We currently have a visual scripting system similar to blueprints in Unreal - connecting nodes. The proposal here is for a second visual scripting system, that is similar to event sheets in Construct 2 (proprietary), Multimedia fusion (proprietary) and Gdevelop (open source) 11 GD-clickteamesque-additionOfEvents

    It is a very different approach from the one with blueprints and people learning to program are still requesting it on facebook and other godot community forums

    What is an event sheet visual script in the other engines: https://www.scirra.com/manual/44/event-sheet-view The event sheet is pretty much a spreadsheet with two columns - a conditions column and an actions column. Both columns can be populated with logic blocks from nodes and their children that the sheet is attached to (node methods). On the left column the user can only attach conditional methods, on the right - only action methods. This clear divide makes for a very easy to learn way of setting game logic. On top of that the user can use expressions in both columns - so potentially use gdscript for more specific instructions.

    Rows can be nested under other rows (called sub-events), can be commented, disabled or re-enabled (just like commenting code) https://www.scirra.com/manual/128/sub-events subeventexample Some actions/condition blocks can be negated

    Functions that can take parameters can be used as well, by using a special function condition block and nesting conditions/actions under its row image28 modifiedcheckmatches

    So What are the advantages over our current visual script:

    • It is an alternative style of visual scripting with a big following - a quick look at the number of users of construct 2 and the number of succesful 2d games made with clickteam fusion should be a good enough indicator. It has also been requested on Unity forums too https://feedback.unity3d.com/suggestions/create-a-visual-scripting-for-begginer-like-construct-2-or-behavior-machine https://feedback.unity3d.com/suggestions/visual-scripting-based-in-event-sheets-as-construct-2

    • It is easier to learn and arguably clearer for non-programmers

    • An event sheet can pack much more information of the game logic on one screen than blueprints - less scrolling and panning to get the information. Less wasted empty space between logic blocks. You can technically just take a screenshot of an event sheet and share it to show someone else how to do something. 6708 image_2e2b4e43

    • It is easier to transition learning from event sheets to scripting - because it's more similar to scripting than blueprints

    • Why is it easier to learn than blueprints - the clear divide of condition and action and obvious order of execution. The user gets a filtered list of things to do on the two columns.

    • Logic blocks are easy to quickly read/find because they have icons. Most nodes in godot also have icons - they can be reused for the event sheet implementation

    • Less clicks needed to get things working - no need to connect nodes or move nodes on the blueprint table. You just add or drop logic blocks in the cells. No need to pan at all- you only scroll and its much less.

    In any case, I am writing this proposal not to say that one system is better than the other - but more with the hope of sparking interest in developing an alternative to our custom visual scripting approach - an alternative that is popular amongst people learning to code and that is a great transition to gdscript - as I found out from first hand experience

    Addon progress report 0

    Here is a crude mockup so far: capture

    Demos of event sheet style systems that you can try online(no log in required): https://editor.gdevelop-app.com/ https://editor.construct.net/

    Event Sheet System Possible Structure:

    |_Event sheet established variables and connections tab
    |_Event sheet script tab
      |_Function(built in or custom)
          |_event sheet row (can be parented to another event sheet row or an event sheet group)
              |_Actions column
                   |_Action cell (richtex label) (click to open another window to edit)
              |_ Conditions Column
                   |_Condition Cell (richtex label)(click to open another window to edit)
    |_Action/Condition Cell Expression Editor
      |_Gdscript editor instance - to be used for expressions
      |_Easy Click interface to access the available subnodes - their nodepaths and methods- clicks bring up menu that populates the expression editor - similar to Clickteam Fusion's
    

    Inner workflow: Event sheet resource can be attached to node -->on runtime it generates a gdscript and that is used by the game

    Addon progress report 1

    I did some work on the addon's most important building block- the event sheet cell

    es-adding

    Some background in what it does - Basically the event sheet is made out of cells. A cell can contain either conditions (getters/expressions) or actions (setters that can be fed with getters/expressions). On the GUI side, the event cell is created via a richtextlabel node and bbcode that is generated from gdscript. When you double click on it, the richtextlabel turns into an editbox node containing the actual gdscript expression.

    So an event sheet cell has 2 modes:

    • edit mode - textEdit node that can be typed into with gdscript. The only difference is that the user does not need to type in If/else/while - that is context sensitive to the parent container as seen in the screenshot. Every line is a new condition, so if the user hasnt started the line with "or" or somethind else, the parser automatically knows that a new line has "and" pretext

    When clicked away, switches to view mode.

    • view mode - richtext label - When switching to view mode, a bbCode gets parsed from the gdscript that is in edit mode and presented via an interactive richtext label. Apart of being interactive and easy to change , the goal is to present the gdscript code in a clearer way. This means showing the node's name and icon only (not the entire path) and getting rid of some words, when its obvious (such as get_ and set_). Since every clickable part is actually a url tag, when hovering over a node name for example - the user can get some information, such as the full path of the node.

    About the Add new condition/Action menu: This is what creates a new gdscript line of code for a condition or an action. Whats great about it is that it lets you easily browse all of the nodes inside a scene and their methods - it sort of works in an inverted way to how autocompletion works in gdscript's editor. It shows all nodes and all of their setter, getter or both methods. You can then narrow down to what you want via a filter. If callend from a condition cell, this menu shows only getters, if called from an actions cell, it shows both setter and getter methods.

    Note that this is still full of bugs and not even half complete to share, but hopefully makes it clearer what I am proposing

    Progress report 2 Made some planning on how it can work. Also looked into what needs to be refactored before presenting the concept addon

    I made this flowchart to explain how it works at the moment https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml eventsheetmockupplan Decided to refactor it to generate typed gdscript #19264 Its much easier to create bbcode links for further helper menus when its typed

    archived discussion feature proposal topic:visualscript 
    opened by blurymind 192
  • Tilemap/draw_rect random flickering with Nvidia drivers

    Tilemap/draw_rect random flickering with Nvidia drivers

    Operating system or device - Godot version: Windows 10, godot3.0alpha1

    Issue description: I made a kinematicbody2D and a tilemap, moving the kinematic body around worked as normal however occasionally one of the tiles on the tilemap would vanish faster than any screen recording software could capture. sometimes 2 would vanish, they would get redrawn however

    Steps to reproduce: Make a tilemap, load some tiles in, make a kinematic body move the body around the game, keep your eyes open, dont blink, watch as some tiles vanish from rendering and quickly come back

    bug confirmed topic:rendering 
    opened by NullNeska 192
  • Bullet physics engine implementation

    Bullet physics engine implementation

    It's long time that we talk about this. and finally today I'm submitting the PR.

    Note

    Before present my job I want highlight some things. This implementation is not intended to completely overwrite the current godot implementation, infact by going to the the project settings is possible choose which Physics engine to use so the developer has 100% freedom about which engine to use (the default is the current Godot physics engine). Godot - physics engine select

    The other thing is that by using bullet physics engine we are not changing nothing about the old usage of Godot. All the old known ways used to handle the physics in the games remains untouched at all. I've made some videos where I compare the two physics engine and the only thing I did to swap the engines was select GodotDefault or Bullet in the settings.

    There are two things to implement vehicle and kinematic character, I'll implement these if this PR will be accepted. The SCsub file must be improved to allow more customization of Bullet.

    Presentation

    Thanks to the good concept of Godot implementation I was able to implement Bullet in a natural way.

    In this video https://www.youtube.com/watch?v=NYLQSaMXHmg I show the areas and the trimeshes that works perfectly, I want to point out that the areas can be used as trigger or space modificator, like is done by default Godot. In this video you can see all the balls that falls down under a limit enter inside a trigger area that destroy it. Another thing is that as you can see Bullet manage better the trimesh collisions and the balls movement.

    In this video https://www.youtube.com/watch?v=4X4GRbmfSnc I want to show you the improvements that Bullet port and for this reason I show three tests. The first test show the joints implementation, So I've made a chain with dynamics number of elements. Using godot physics engine we are limited to 88 elements, but with Bullet we can go further to 300 with 30FPS. The other test I test a slider, hinge, 6DOF + motor joints and with Godot physics it doesn't work at all. The last test I made is usefull to demostrate that Bullet support perfectly the method of godot to create multi shaped bodies

    Conclusion

    As you can see by implementing Bullet physics engine we have the access to a very stable physics engine, that is a lot know and well documented, without losing any performance. We also have the possibility to focus more on the implementation of new featurs like Cloth / soft bodies, or improve performance of trimesh by using vertex reduction utility. And improve the vehicle stability. I've also implemented the heightmap shape so when we'll implement the possibility to create the height field inside the engine the collision shape is ready to work.

    I think this is a good feature and improvement that speed up the implementation of the engine and port even more interest about the third version of this engine, that with the new rendering engine and withy a stable physics engine make this game engine even more competitive. I don't want provide it as a GDNative because I want implement the things that I've pointed above (clothing) that are impossible to support using GDNative since I need to make some changes to engine code.

    feature proposal topic:physics 
    opened by AndreaCatania 188
  • UI Concept for Godot

    UI Concept for Godot

    Hi there,

    This weekend I worked on a conceptual UI for Godot. My focus was on getting a clear and coherent design that can be flexible (fully dockable) and easy to expand in the future, and also up to date with current UX patterns on most 3d related apps. Please take a look and tell me what you think. The concept was first posted on the Godot IRC channel. Thanks to @xodene for the idea of posting the design here.

    gdoto_basic_layout_concept_01

    About the design

    • Font used is Source Sans Pro, an open source font made by Adobe. This font has many weights and alternatives, including an mono spaced version, which suits perfect for scripting.
    • Current icons are from Font Awesome, a set of open source icons well known in web development. My plan is to make a complete set of custom designed icons for Godot, but this could take a lot of time, so for know I sticking with this icon set, just for testing purposes.
    • I took some freedom an added random icons and features, this helps me to see how the layout works.

    Update on Oct 13, 2015 Hi everyone! I finally got time to continue my work on the UI. Here is a quick update on the interface that include some of the features you mentioned on the comments.

    gdoto_ui_concept_02

    I also want to share with you a logo design concept I have been working on in parallel with the UI. This logo is my attempt to a fully coherent and modern Godot visual identity that initially starts with the UI design. Here I tried to simplify the current logo and make it more serious, solid and unique; as well as play well with different sizes and colors.

    gdoto_logotype_concept_01

    As always feel free to let any feedback you want; that's best way to iterate!

    discussion enhancement topic:editor usability 
    opened by alelepd 187
  • C# as scripting language

    C# as scripting language

    I could not find any other issue mentioning this, so I suppose most discussion about it happened over IRC.

    In #5049 we discussed some things about scripting, and some said the Godot team is considering C#.

    C# is a great language with many features, but I personally think that considering Java 8 is a much better language than Java 6, has a better runtime across many platforms and a better JIT and GC than the CLR (unless things changed in the last year), Java could possibly be a better candidate.

    Unity might use C#, however Godot never set out to be a Unity ripoff. Java is much more popular than C#, according to this site and job postings, and there are many game developers (especially on Android) who use Java.

    Additionally, many of the features that C# offers compared to Java are not much important if the purpose is scripting, as most scripting in games is imperative and (at worst) object-oriented (and many of the advantages C# offers are related to functional programming, which Java 8 supports decently anyway). Just take a look at your average Unity script, even a more complex one like this: there's not much there that can't be done in Java straight away!

    The JVM also offers a good amount of other languages - Kotlin, for examples, which has many features like nullable types, pattern matching and operator overloading. There's also Ceylon, which is in many ways a better C# (and compiles directly to JavaScript). Supporting those would not require any more work than adding a JAR dependency. Java also has a larger amount of libraries.

    And if performance is the main concern and a runtime like the CLR and JVM is too heavy, those can be done away with and C++ could be used directly via LLVM, so that a JIT can be used, avoiding expensive recompilations. This solution is best kept along with GDScript, so that novices (or people who don't need extra performance) can use that instead (and avoid segfaults). The latest standard of C++ has very clean syntax, so I don't think verbosity should be a problem.

    C++ is the solution I would like the best, because it would bring the fastest performance (zero overhead, can't be said for any other language), it would not need any extensive changes (as Godot can already be used from C++, and is written in C++ itself), it would have the more consistent support across platforms and it would make it possible to use Godot for very large projects (such as AAA games - there's a reason most studios use Unreal and not Unity). Additionally, keeping GDScript would let those people who don't need extra performance an easier way to write scripts than Java or C# (both very verbose languages) would be.

    tl;dr: I think C++ (or worse, Java 8) makes a better choice than C# for scripting in Godot.

    Any opinions?

    Edit: I see the "feature proposal" tag (which is correct) but I want to make it clear that I'm not proposing C# support in Godot, I'm merely reporting and commenting on some of the things I've heard around.

    discussion feature proposal 
    opened by ghost 161
  • Heavy stuttering issue in simple 2D game [Windows 10, Nvidia]

    Heavy stuttering issue in simple 2D game [Windows 10, Nvidia]

    Godot version: Godot 3.1-dev / Godot 2.X

    OS/device including version: PC - Windows 10, GeForce GTX 1060 6 GB, 16 GB RAM.

    Issue description: Stuttering / jitters when moving a 2D Sprite. Reproduced on 2 computers (with nvidia graphic cards, the one above and a laptop), a friend of mine reproduce this issue too.

    Steps to reproduce: I just download the "First project" that we can make in the documentation. I have tested to reproduce the first part of this tutorial to only have the player and nothing else. If I run it without change anything. I have some stuttering at the same as the game run with 60 FPS. The motion is not smooth. I collaborate with a dev to try to reproduce this problem and try to understand the issue. I have made a lot of test (Run from editor, run after compilation without debug mode etc...But when I deleted the animation, all run smoothly.

    PS : it seems that physic behaviour make sprite stuttering too (try with kinematic and Area2D node with collision). If I desactivate collision and replace Area2D with a simple node2D there is no stuttering (if I don't play any animation on the player).

    Minimal reproduction project: Here's a minimalist project (that comes from the first game project of the documentation). If I run it, I have some stuttering. If I delete the player animation I have no more stuttering. FirstGame.zip

    bug platform:windows topic:core 
    opened by crystalnoir 145
  • Problems with preventing

    Problems with preventing "engine bloat" and the AssetLibrary

    Sorry for the very long post. I'm not mad if you don't want to read the whole thing, so here's a short version of it.

    This is a mashup or many different issues. I didn't know where a comment like this would have been appropriate, so here it is in its own issue.

    TL;DR

    Using assets should feel like using core-functionality. Currently it doesn't. Proposed fixes:

    • add proper dependency manangement with system wide installs of assets. Move addons out of the project itself with a way to bring them back for modification
    • make it easier to extend custom nodes, allow cross-language script inheritance
    • allow scripts to be referenced by class name and namespace to avoid super long paths in case of assets.

    Related issues: #19178 #17092 #15661 #13187 #10635 #7402 #6277 #5947


    Details here ⇓

    Godot is amazingly powerful for the size of the binary. Unity and Unreal are bloated in comparison, but they do offer more QoL functionality out of the box.

    The situation with Godot is that there are some PRs that add good and useful new nodes which are rejected since they are "easy to code in GDScript and don't need to bloat the engine". This is a very valid and reasonable reaction - if Godot should stay a < 40 Mo download then adding new Nodes and features needs to be justified.

    While I do think this is a nice approach that ensures a pretty clean core, it has some problems.

    Criticism and problem description

    1. Functionality in core is official and undergoes quality control

    If there's an InterpolatedCamera Node in Godot, I assume that's the interpolated camera most people use, I assume that it's the most developed and "optimized for the engine" one since it's the one that's part of the engine. It has something official about it.

    The good thing about a "bloated engine" with many features is that those features are official and most likely the most widely used ones, more tutorials and documentation about them etc. They have been tested in many projects and there's a single place to discuss how to improve them.

    I, as a game developer, prefer official nodes over custom ones written by Some Person. Of course this approach has downsides, like huge download sizes, longer loading times and other nasty things. BUT I think in terms of user friendliness, official features are preferred over custom addons. Which one of the 4 InterpolatedCamera assets should I use? How do they differ? Is the documentation good enough? Where's the issue tracker? etc etc...

    2. Downloaded assets from the AssetLibrary are just copy pasted into the project

    There is no difference between an Asset from the AssetLibrary and some code/scenes from the "main project". However, there is a difference between "official" Nodes and Nodes imported from the AssetLibrary.

    If I wanted to add some custom behavior to one of my InterpolatedCameras, I could add a script on it and add my functionality - all cool and nice!

    If I wanted to add some custom behavior to one of my AssetInterpolatedCameras, I could add a script on it and - oh. Attaching a script to a custom Node actually replaces the script. The very same script that is the reason I downloaded the asset. This is an editor problem and a core problem at the same time.

    Problems:

    1. Script inheritance isn't suggested when attaching a script - override is the default for those cases.
    2. Script inheritance doesn't work cross-language. A project that uses C# can't extend the camera with C#, while this would be possible with an official node.

    Fixes:

    1. Make the editor fill in the path of the already existing script as the base type so script inheritance is the default. But this doens't solve the problem when you want to clear your custom script for that one camera as it would just remove all scripts entirely.
    2. Make script inheritance part of the Script API. Currently the scripting languages all do script inheritance on their own - they don't know how to deal with other languages. My suggestion is to add a set_base_script that accepts every type of script. Usually the scripting language implementations just use the Script API on the base class anyway, so this could be generalized.

    The problems of "copy-pasting assets into the project gets amplified by the fact that all scripts are only defined by their path.

    In the camera case, I could do var camera = InterpolatedCamera.new() with an official Node, but I would basically have to do var camera = preload("res://addons/com.name.interpolated_camera/scripts/interpolated_camera.gd").new().

    This is more than suboptimal. I know that reduz opinion is that paths are easier to use than class names, but I know for a fact that multiple users would prefer an optional alternative system that uses namespaces and class names instead.

    Especially in the context of downloaded assets, this would be a huge improvement.

    Proposed solution

    Downloading assets and using them should feel like they are part of the engine. If they engine is kept small and meant to be extended with assets, that workflow has to be made as seamless as possible.

    The basic goal is to make using assets feel like using core-features.

    My proposed solution is a mix of a few existing discussions, but I think this is the place where all of them would shine together.

    1. Make the AssetLibrary more package-manager like

    • Having a dependencies.json could be good enough. Using the AssetLibrary UI in the editor would just fill in the json, the download and installation happens at another time. An asset can itself have dependencies.

    • Assets are saved with version associated, all stored in .local/godot/assets or something like that. They are no longer part of the project itself but available system wide.

    • At export the needed files can be copied into the .pck.

    • Have a way to actually copy the files into the project in case modification at the source level is desired. Only then the files should be brought into the project folder itself. "Cloned" assets could live in a hidden folder like .custom.

    2. Make using downloaded scripts easier

    • add a ScriptDB kind of system that can be used to reference classes without knowing the exact path

    • add support for cross-language script inheritance

    Conclusion

    I know this is a very long post, but I hope to spark some more discussion on the AssetLibrary and also usability side of things. I think making using assets as smooth as possible is important. While things like proper versioning and allowing sub-projects will help, I think it's not enough to shift the focus to a more AssetLibrary focussed use of the engine.

    archived discussion topic:assetlib topic:editor topic:plugin 
    opened by karroffel 144
  • Collapse the top menus

    Collapse the top menus

    Taking advantage of the current UI changes being done for 3.0, I was thinking that we could also improve the menu buttons on the top.

    Currently, the top-left is occupied by

    • Scene
    • Tools
    • Export

    Tools only have one item, making it actually kind of like a button. Export is a button, not a menu.

    On the top-right:

    • volume bar?
    • settings
    • weird icons that nobody understands what they are for :p

    I thought in 2 different proposals for a change:

    1. Collapse the top-left buttons into just one, maybe call it "Project"?. This means the scene menu will have 2 more items, and we get rid of tools and export, which are seldom used anyway.

    2. Since the space is not being used for anything else, make a more functional menu "bar", and split some items into different menus to make things easier to find. I'd also bring the Settings menu on the right, to join the left side. Project settings could be inside it, together with Editor Settings

    WDYT? :)

    discussion enhancement topic:editor usability 
    opened by nunodonato 143
  • Light2D rendering inconsistent with multiple objects in GLES3 in Godot 3.3

    Light2D rendering inconsistent with multiple objects in GLES3 in Godot 3.3

    I did not see this issue specifically listed elsewhere.

    Godot version: 3.3

    OS/device including version: Windows 10, GLES3, NVIDIA GEFORCE GTX 1660 ti, driver 442.3

    Issue description: When using GLES3 rendering, objects interacting with light2d start to behave differently when multiple objects on screen are also interacting with the light. When you add objects, others get dim. Moving the objects around can sometimes change what dims. Overlapping objects will cause some dim ones to light up.

    This does not appear to happen in GLES2.

    Steps to reproduce:

    1. Create a 2D scene with GLES3
    2. Add light2d
    3. Add a sprite with normal map
    4. Duplicate the sprite node several times
    5. Move the objects around, overlapping them at times, and watch how the light changes on the objects.

    Minimal reproduction project: 2D_Light_Problem.zip

    https://user-images.githubusercontent.com/229208/116967145-aab8e480-ac7f-11eb-90c9-c174683bfdc3.mp4

    bug regression topic:2d topic:rendering 
    opened by HeroicNate 1
  • Cleanup vulkan capabilities check and add multiview check

    Cleanup vulkan capabilities check and add multiview check

    While working on #48207 I cleaned up the checking code in the Vulkan driver for subgroups and made sure output was only logged when release_debug or debug was being used as it's overkill in release.

    As the multiview work will probably takes some weeks if not months to complete just extracted the relevant changes into a separate PR that we may want to merge in already.

    enhancement topic:rendering 
    opened by BastiaanOlij 0
  • Add `editordeps` folder with scons toggle opt and EDITORDEPS_DISABLED macro flag.

    Add `editordeps` folder with scons toggle opt and EDITORDEPS_DISABLED macro flag.

    Lays the foundation for godotengine/godot-proposals#2063. Whether or not it closes the issue depends on whether we want to leave it open for people to suggest things that should be refactored out or delegate that entirely to separate proposals.

    /editordeps can now have source code files added to it which can safely be accessed from /editor and anything in /modules. It is assumed that /core, /servers, and /scene have been loaded prior to /editordeps and that /editordeps is loaded before /editor (at least, to my understanding. Someone should check my SConstruct code since I'm not experienced with it).

    Modules that reference it should take care that their code is wrapped in a flag check though since the editor dependencies can be independently added or removed from the build similar to Advanced GUI and 3D features. Example:

    #ifndef EDITORDEPS_DISABLED
    #include "editordeps/summator.h"
    #endif
    

    The SConstruct file prints an error and exits early if users attempt to build with disable_editordeps=yes tools=yes.

    If people want to change the name of the directory/option/macro, that's fine too. I have no preference.

    opened by willnationsdev 0
  • Calling an external setter function from the setter block results in a stack overflow and a hard crash

    Calling an external setter function from the setter block results in a stack overflow and a hard crash

    Godot version: 8abd50359ba7b5af38a4ceedba287b4459e5f925

    OS/device including version: Windows 10

    Issue description: When using a setter, if you attempt to use an external function as part of the setter, the engine with suffer a stack overflow and a hard engine crash since there's no protection against cyclic recursion.

    Steps to reproduce: Simply run the example project to observe the crash

    Minimal reproduction project: setter_test.zip

    bug crash topic:gdscript 
    opened by SaracenOne 0
  • Language server string autocomplete place undesired quotes

    Language server string autocomplete place undesired quotes

    Godot version: 3.3

    OS/device including version: Ubuntu

    Issue description: When autocompleting strings, the language server puts undesired quotes.

    Steps to reproduce: See video

    https://user-images.githubusercontent.com/1168582/116951932-b1376400-ac5f-11eb-9eb5-a3d940c7ef32.mp4

    Minimal reproduction project: Any GD script file

    opened by jcostello 0
  • Remove repeat from forward mobile renderer

    Remove repeat from forward mobile renderer

    The clustered renderer has an optimization where using mesh instances with the same mesh they can be rendered in a single draw call. This does not work in the mobile renderer as only a single position can be stored in the push constant. Had to remove this logic from the mobile renderer.

    Fixes #48424

    bug topic:3d topic:rendering 
    opened by BastiaanOlij 0
  • Allow values > 1 for friction and bounce in PhysicsMaterial

    Allow values > 1 for friction and bounce in PhysicsMaterial

    Allows friction and bounce in PhysicsMaterial to be set with values higher than 1 in the editor, but still doesn't allow negative values and clamps the slider between 0 and 1.

    Fixes #48298 Supersedes #48321

    bug cherrypick:3.3 cherrypick:3.x regression topic:physics 
    opened by pouleyKetchoupp 2
  • rid/raster errors on first run of project in 3.3

    rid/raster errors on first run of project in 3.3

    Godot version: 3.3

    OS/device including version: Linux mint 64

    Issue description: I'm sure this is benign, but on running my project for the first time on opening Godot I always get these errors and only in 3.3. On subsequent runs from within Godot it does not appear. Close Godot and reopen project and it appears again on the first run, etc.

    image

    I have swapped back to 3.2.3 and everything is fine, there are no errors, I go back to 3.3 and it appears again on first run.

    Is this ok or a sign of something wrong with 3.3 that needs more data from me?

    opened by chucklepie 0
  • UPDATE_CAPTURE in Animation's Track has some strange behavior

    UPDATE_CAPTURE in Animation's Track has some strange behavior

    Godot version: 3.2.2, 4.0.dev

    OS/device including version: MacOS 10, Win 10

    Issue description: In AnimationPlayer, tracks with UPDATE_CAPTURE will make a mess of loop and loop_wrap option.

    Same as linear interpolation, but also interpolates from the current value (i.e. dynamically at runtime) if the first key isn't at 0 seconds.

    https://docs.godotengine.org/en/stable/classes/class_animation.html

    The documentation says above, but it behaves differently than linear interpolation when looping. Also, it is not consistent in behavior between AnimationPlayer and AnimationTree. Moreover, the behavior is also inconsistent between normal and reverse playback. So, it is hard to know what is a bug and what is correct behavior.

    And... it may be an exaggeration, but I think that if all the behaviors of UPDATE_CAPTURE are not yet decided, we should consider discontinuing it.

    Steps to reproduce: Try looping the track with the UPDATE_CAPTURE option set, and try switching the loop_wrap option. Also, try playing it backwards and try playing it back in an AnimationTree.

    Minimal reproduction project: capture_test.zip

    opened by TokageItLab 0
  • Fix property warning when updating inspector

    Fix property warning when updating inspector

    Fixes #46289

    The warning came from here: https://github.com/godotengine/godot/blob/f47c285f678345f5fde6937deb8bd740589beb83/editor/editor_inspector.cpp#L2473-L2481 Now, I don't 100% understand this code, but my assumed cause of the bug is that the inspector was pending update (and presumably the properties were invalid at this time), but the update happened after a cache check on the properties was run. is_cache_valid() eventually triggered a warning, because the property didn't exist.

    This could potentially be fixed by re-arranging the code, but the change I did is safer.

    bug regression topic:editor 
    opened by KoBeWi 0
Releases(3.3-stable)
Owner
Godot Engine
Godot is a popular Free and Open Source game development engine and toolset.
Godot Engine
the thin c++ game engine

CI Community Support toy is a thin and modular c++ game engine. it aims to provide the thinnest and simplest stack of technology for making games dire

Hugo Amnov 1.4k Feb 18, 2021
An open source re-implementation of RollerCoaster Tycoon 2 🎢

An open source re-implementation of RollerCoaster Tycoon 2 ??

OpenRCT2 9.2k Mar 17, 2021
Godex is a Godot Engine ECS library.

Godex Godex is a Godot Engine ecs library. Disclaimer: this module is still in development, open an issues to report any problem or a new discussion i

GodotECS 285 Mar 3, 2021
Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve external game process read/write with minimum footprint.

Launcher Abuser Stealthy way to hijack the existing game process handle within the game launcher (currently supports Steam and Battle.net). Achieve ex

Ricardo Nacif 55 Apr 24, 2021
Design-agnostic node editor for scripting game’s flow in Unreal Engine

Flow plug-in for Unreal Engine provides a graph editor tailored for scripting flow of events in virtual worlds. It's based on a decade of experie

Moth Cocoon 24 Apr 3, 2021
Full source code for WarriOrb, a Dark-Souls like action platformer - using Unreal Engine 4

WarriOrb source code WarriOrb is a hardcore action platformer where you play as a demon who is trapped in an unlikely body. The game mixes the difficu

Not Yet 120 Mar 19, 2021
Project 1945 is a top down scroller game made with SDL2, CMake and programmed in C as a project of study for the Italian Videogames Academy for the 3rd year course of Videogames programming.

Project 1945 is a top down scroller game made with SDL2, CMake and programmed in C as a project of study for the Italian Videogames Academy for the 3rd year course of Videogames programming. The game is based on the old videogame 1945: The Final Front of the 2002.

null 13 Feb 7, 2021
A simple text-based adventure game

The Lighthouse of Doom This repository contain a simple text-based adventure game, implemented twice, once in portable C, and once in Z80 assembly lan

Steve Kemp 35 Apr 29, 2021
DOSBox Pure is a new fork of DOSBox built for RetroArch/Libretro aiming for simplicity and ease of use.

DOSBox Pure is a fork of DOSBox, an emulator for DOS games, built for RetroArch/Libretro aiming for simplicity and ease of use.

Bernhard Schelling 300 Feb 23, 2021
🎮 Fully featured terminal version of the game

?? Fully featured terminal version of the game "2048" written in C++

Mihir Chaturvedi 1.7k Mar 17, 2021
Improved version of the X-Ray Engine, the game engine used in the world-famous S.T.A.L.K.E.R. game series by GSC Game World.

OpenXRay OpenXRay is an improved version of the X-Ray Engine, the game engine used in the world-famous S.T.A.L.K.E.R. game series by GSC Game World. S

null 1.5k Feb 18, 2021
D2DX is a complete solution to make Diablo II run well on modern PCs.

D2DX D2DX is a preservation project for running classic Diablo II/LoD on modern PCs. Version 0.99.403b Mission statement Turn the game into a well beh

null 13 Apr 3, 2021
Flax Engine – multi-platform 3D game engine

Flax Engine – multi-platform 3D game engine

Flax Engine 2.3k Mar 17, 2021
Reimplementation of the Diablo2 game coupled with patching facilities for modders.

D2MOO - Diablo II Method and Ordinal Overhaul This project is a re-implementation of the Diablo2 game coupled with patching facilities for modders.

The Phrozen Keep 14 Feb 17, 2021