+ 
+
+
+ {{ post.excerpt }}
+
+ Used to export your games to all supported platforms.
+
+ Used to export your C# games to the supported platforms.
+ Currently, the C# version can export to desktop platforms (Linux, macOS and Windows), Android, iOS, and
+ HTML5/WebAssembly.
+
Use it to develop Android plugins in Java or Kotlin using the Godot API.
+Use it to develop Android plugins in Java or Kotlin using the Godot API.
+
+ Blender add-on to export scenes to Godot's scene format directly.
+ Godot also supports glTF 2.0 and OBJ.
+
+ + Godot's development is open. This means that you can + fix or improve any part of the engine yourself and choose + whether to contribute it back or keep it private. +
++ New features are always available to use and test, without the need of + having to wait for the next major release. Compiling Godot from source + is very easy and the process is well-documented for each platform. + To obtain the source code, please visit the + GitHub project page. +
+
+ {% endif %}
+
+ {% if page.macos %}
+ 
+ {% endif %}
+
+ {% if page.linux %}
+ 
+ {% endif %}
+
+ {% if page.switch %}
+ 
+ {% endif %}
+
+ {% if page.html5 %}
+ 
+ {% endif %}
+
+ {% if page.android %}
+ 
+ {% endif %}
+
+ {% if page.ios %}
+ 
+ {% endif %}
+
+ {% if page.playstation %}
+ 
+ {% endif %}
+
+ {% if page.xbox %}
+ 
+ {% endif %}
+
+ + {{ page.developer_interview.text }} ++ + {% if page.developer_interview.url %} + {{ page.developer_interview.context }} + {% else %} +
{{ page.developer_interview.context }}
+ {% endif %} +
+
+
+If you host a physical or online community, feel free to add it to the list by editing the top of [`user-groups.html` in the godot-website repository](https://github.com/godotengine/godot-website/blob/master/themes/godotengine/pages/user-groups.htm) and opening a pull request. Make sure to group it with other communities in the same country (if any).
+Alternatively, you can also send an e-mail to *webmaster at godotengine · org* to request your community to be added to the list.
+
+For the curious, the map is powered by the open source [Leaflet.js](https://leafletjs.com/) library and uses the [Mapbox Static Tiles API](https://docs.mapbox.com/api/maps/#static-tiles). You can view the implementation in [this pull request](https://github.com/godotengine/godot-website/pull/201).
\ No newline at end of file
diff --git a/collections/_article/announcing-new-hire-gilles-roudiere.md b/collections/_article/announcing-new-hire-gilles-roudiere.md
new file mode 100644
index 0000000000..4233472372
--- /dev/null
+++ b/collections/_article/announcing-new-hire-gilles-roudiere.md
@@ -0,0 +1,22 @@
+---
+title: "Announcing a new hire! (Gilles Roudière)"
+excerpt: "In the past month, the excess donations accumulated so we are finally able to offer enough security to do an extra hire. Beginning November, Gilles Roudière (Groud) will be working full-time for the project, dedicated to 2D and general editor usability!"
+categories: ["news"]
+author: Juan Linietsky
+image: /storage/app/uploads/public/5f4/66c/b1b/5f466cb1b23ec647588316.png
+date: 2020-08-26 00:00:00
+---
+
+In the past month, the excess donations accumulated so we are finally able to offer enough financial security to do an extra hire. Beginning November, [Gilles Roudière (Groud)](https://github.com/groud) will be working full-time for the project, dedicated to 2D and general editor usability!
+
+## Background
+
+Gilles is responsible for the 2D editor in Godot, as well as some other areas such as the current filesystem dock and several improvements to Godot UI nodes. He has done an outstanding job, producing top quality contributions.
+
+His main responsibility from now on will be to become the general editor maintainer. He will work on improving usability, adding features, and making sure that the experience with the built-in tools is the best as it can be.
+
+Immediate priorities include improvements to the tilemap editor, animation editor, skeleton animation editors, and general 2D editor experience. Further ahead, more general improvements for the editor overall, based on your [proposals](https://github.com/godotengine/godot-proposals/).
+
+## Future
+
+We have more hires planned, but we need to increase our donations level for this. If you are not, please [consider becoming our patron](https://www.patreon.com/godotengine) and help make this happen!
\ No newline at end of file
diff --git a/collections/_article/as-oss-godot-is-more-than-a-game-engine.md b/collections/_article/as-oss-godot-is-more-than-a-game-engine.md
new file mode 100644
index 0000000000..f55be20b68
--- /dev/null
+++ b/collections/_article/as-oss-godot-is-more-than-a-game-engine.md
@@ -0,0 +1,110 @@
+---
+title: "As an Open Source project, Godot is more than a game engine"
+excerpt: "Godot is a community developed game engine. The development process is becoming tighter and more efficient every day. As the amount of contributors keep growing exponentially, it's a big challenge for us to keep this process efficient and yet improve it."
+categories: ["news"]
+author: Juan Linietsky
+image: /storage/app/uploads/public/59e/119/c08/59e119c088aec337308530.png
+date: 2017-10-13 00:00:00
+---
+
+# Introduction
+
+Godot is a community developed game engine. The development process is becoming tighter and more efficient every day. As the amount of contributors keep growing exponentially, it's a big challenge for us to keep this process efficient and yet improve it.
+
+In fact, our development process and code quality are, already, arguably in many senses better than commercial game engine counterparts. Proof of this is the large amount of features added on each release, and the ever high stability of the codebase, even on alpha state.
+
+Before explaining this further, It's important to understand what is, according to the point of view in this article, considered to be a game engine, and where Godot stands.
+
+What is, then, a game engine? Let's try to agree on a common point of view.
+
+### A renderer + OS obstraction functions
+
+For a lot of developers, just a renderer plus abstraction on some OS functions (such as input handling, filesystem, etc), is enough to label something a "game engine".
+
+Truth is, I don't think this is fair. In Godot, the renderer is only, at much, 1% of the codebase, and OS abstraction does not even amount to that.
+
+If Rendering and OS abstraction is only, at much, 2%. What is the rest needed for?
+
+### Adding tools to the mix
+
+At some point, a lot of functions are needed for a more modern workflow. Asset importing, exporting, level editors, serialization, etc.
+
+One could then argue, that a game engine is an OS abstraction, a renderer, and tools that help to make a game.
+
+It would be easy to agree that this definition fit the bill a decade ago, but engines from back then definitely are not the same as the more modern ones from today.
+
+Back then, tools were generally separate applications or processes to deal with different aspects of a game. Nowadays, game engines don't look like this (save for maybe in-house engines that large companies still use).
+
+### A Coherent experience
+
+During this past decade, game engines morphed into all-in one tools with an unified interface. The focus was put mainly on usability and a coherent experience.
+
+This made engines migrate from being specialized tools for experts to accessible applications than anyone can use.
+
+Nowadays, it would be difficult to argue that a modern game engine does not include this aspects in it's definition.
+
+There is also something else, though..
+
+### Extensibility and Community
+
+Game engines are meant to be tools that save work on the most common tasks of developing a game but, as game development is a creative process, it's not uncommon to find situations where new features need to be added in order to achieve game design goals.
+
+Due to this, extensibility is a very important aspect of modern game engines.
+
+Building a community around this model is vital for developers to save time on their respective projects. This way, common extensions and features can be shared without having to be reimplemented.
+
+As such, we can agree that extensibility and a user community also fit the definition of a modern game engine.
+
+For some engines, this is even part of their business model. This way, if something is missing, the community can create and sell the missing functionality.
+
+## But then comes Godot
+
+Godot adds something entirely different to the mix. Something both new and old. It's a fully open source and community driven game engine.
+
+It may not make sense what's special about this at first, but once you start using it and taking part of the community, it becomes obvious.
+
+### The Open Source Difference
+
+The open source development process is something beautiful. Once you get it, it becomes clear why. Once a project is set in motion and starts getting traction, it becomes unstoppable.
+
+It may not make sense to most developers how a bunch of guys working in their free time and without getting paid can create quality software that, very often, matches or surpasses it's commercial counterparts.
+
+Projects such as Linux, gcc, LLVM, Python, Videolan, Blender, git, etc. are proof of this.
+
+### The Open Source development model
+
+Many confuse *Open Source* with *Shared Source*, or making the source available.
+
+When you read about *Open Source* somewhere, it's always about the [OSI definition](https://opensource.org/) of it.
+
+It means that a special license is used so everyone collaborating will benefit equally, making the development truly open.
+
+When companies make the source available, they will often do it together with a license where they clearly state that they benefit more from it than anyone that contributes. Alternative, some companies make part of their code open while keeping the rest as closed or under a more restrictive license.
+
+This is what makes Godot different to engines such as Unreal, Xenko, Cocos2D, Lumberyard, etc. Anyone who contributes to Godot, benefits equally from other's contributions.
+
+### Godot is a true Developer Community
+
+This key difference is what makes us stronger in the end. Godot is not just a game engine, it's a true developer community. It encourages everyone to contribute and benefit on equal terms.
+
+We have dozens of core developers and more than 400 contributors working on Godot, and this number keeps growing exponentially month by month.
+
+But this is not all, Godot development is a true meritocracy. Code is only merged when deemed worthy by the other developers. Every change is discussed for pros and cons.
+
+This process is led by our large user community, who usually sets our priorities via issues (or just random rants on our community sites :P). This same community helps with the testing and works directly with developers implementing each feature to ensure it works as best as possible. Our process is truly community-driven from begining to end.
+
+This development process, which involves several thousands individuals, is extremely efficient and ensured that, in a bit less than 3 years, Godot went from being completely unknown to appear on the map on the most important developer communities. No other game related technology has grown so quickly!
+
+To add to that, Godot gives you the safety that we are just individuals working towards making the best game engine possible.
+
+Godot does not need to survive by selling you new features constantly that you probably don't need and just bloat the engine because they are implemented in a hurry. The small 20mb download size is a testament to this.
+
+Godot does not need to sell you assets or extra services to keep the development going, and does not ask you for a % of your income.
+
+Godot does not need to pay high salary to talented developers in order to exist, talent forms around it due to the oppenness of our process.
+
+Godot does not need to convince companies or users that it has a solid cashflow and it won't go away anytime soon. Like every successful open source project, we are a talent pool that constantly self replenishes.
+
+Because of all this, Godot is a lot more than a game engine. It's a lot of talented individuals and the best community we could ever wish for, working together with the hopes of creating the best game development tool that ever exists.
+
+Following this process is very exciting, so stay with us and help us keep making Godot better and better!
\ No newline at end of file
diff --git a/collections/_article/asset-library-web-frontend-reaches-beta.md b/collections/_article/asset-library-web-frontend-reaches-beta.md
new file mode 100644
index 0000000000..507a5f0a41
--- /dev/null
+++ b/collections/_article/asset-library-web-frontend-reaches-beta.md
@@ -0,0 +1,70 @@
+---
+title: "The Asset Library web frontend reaches beta"
+excerpt: "After several months of development, the web frontend to Godot's Asset Library finally reached the beta status!"
+categories: ["news"]
+author: Rémi Verschelde
+image: /storage/app/uploads/public/581/7c8/856/5817c8856eccf877486140.png
+date: 2016-10-31 22:44:33
+---
+
+After several months of waiting ([obligatory joke](https://en.wikipedia.org/wiki/Waiting_for_Godot)) and more importantly of development, the web frontend to Godot's [*Asset Library*](/asset-library/) finally reached the [beta status](https://github.com/godotengine/asset-library/milestone/2?closed=1)!
+
+What does it mean? That the Asset Lib frontend is now [officially public](/asset-library/) and that the community can start using it extensively. It is still [in development](https://github.com/godotengine/asset-library), but we have a pretty solid base that should allow you to create your account, submit and update your assets - as well of course as seeing the existing assets in the library.
+
+Many thanks to [Bojidar Marinov](https://github.com/bojidar-bg) for the huge work he did on the Asset Lib so far! [Others](https://github.com/godotengine/asset-library/graphs/contributors) have started to contribute too, don't hesitate to join in if you like (or at least know) PHP :)
+
+If you missed the inline links, here they are in clear:
+
+* [Asset Library](/asset-library) - browse anonymously or register and login to submit new assets
+* [Source repository](https://github.com/godotengine/asset-library) - to partake in the development
+* [Issue tracker](https://github.com/godotengine/asset-library/issues) - to report any issues you may encounter (also usability wise, it's still a work in progress)
+
+## How does it work?
+
+The Asset Library is composed of three parts:
+
+* The engine frontend in Godot itself (since 2.1 stable), that you can access via the project manager (to install templates and demos) or via the *AssetLib* tab in your opened project (for all other types of assets).
+* The web backend, which is queried by the engine frontend to retrieve the list of assets and related metadata.
+* The web frontend, which allows you to see the contents of the library in your browser ([see this asset](/asset-library/asset/4) for example), and most importantly to submit new assets and edit existing ones registered to your account.
+
+## What assets can be submitted?
+
+The exact policy for the Asset Lib still needs to be formally written down, but here are the general rules that apply so far:
+
+* All assets should be licensed under a *free and [open source](https://opensource.org/osd) license* (e.g. MIT, BSD, GPL, CC0, etc.). When picking a license for your assets, you should of course ensure that you have the appropriate rights (i.e. you can't relicense assets from someone else to submit them to the Asset Lib).
+* All assets should be hosted in a [Git](https://git-scm.com/) repository, and accessible through a web frontend. The supported frontends so far are GitHub, GitLab (both gitlab.com and self hosted), Bitbucket, gogs and cgit (those two are also typically self hosted).
+* Each asset should be hosted in its own Git repository, i.e. one asset = one repo.
+
+Why do we request this? We are not a company, and we want to give the priority to open source contributions that will benefit all users without having to care for the legal burden of running a commercial asset store. It does *not* mean that Godot's engine frontend will not support paid assets in the future, but it is not our focus right now for the godotengine.org platform. People who want to run commercial stores are free to extend on our (obviously open source) [web frontend and backend code](https://github.com/godotengine/asset-library) and to host their own platform that can talk to Godot.
+
+We also enforce the usage of Git and code hosting platforms such as GitHub or GitLab for security reasons: it allows moderators to review the code included in each asset before accepting them. The specific commit or git tag provided as the version to download in the Asset Lib can be used to generate an archive with a unique cryptographic hash – moderators have to enter this hash when they accept new assets or edits, and Godot users will only be able to download files with a valid hash from within the engine – this ensures that what users download is what moderators approved.
+
+## How to submit/edit assets
+
+Once logged in, click "Submit Asset" in the navigation bar. You will then see a form asking for various details about your git repository and the asset you want to package:
+
+* Asset name
+* Category: 2D Tools, 3D Tools, Shaders, Materials, Tools, Scripts, Misc, Templates, Projects, Demos (subject to change as we gather community feedback)
+* Frontend type: GitHub, GitLab, Bitbucket, gogs or cgit
+* Repository URL
+* Download commit or tag: this identifies the version you want to submit to the Asset Lib. It will not be automatically updated for the security reasons mentioned above, so please edit your asset to update this hash or tag when needed.
+* Icon URL
+* License
+* Description
+* Optionally image and video previews
+
+Once you submit your asset, you will have to wait for an Asset Lib maintainer to review it and accept it (it can take several hours, though we're usually quite fast).
+
+## How to setup assets in your git repositories
+
+We will provide more information about this in the docs in the coming weeks, but in the meantime, please check existing assets and their git repositories to see how it was done.
+
+Keep in mind that assets are unzipped directly at the root of your project's folder. Therefore, for plugins, you should use a `addons/yourassetname/` folder in your git repository.
+
+If you are in doubt, don't hesitate to ask for guidance on one of the many [community channels](/community)!
+
+## Future developments
+
+As you will probably notice, the frontend is not finished yet. For example, rating assets is not implemented in the beta. You can check the existing [list of issues](https://github.com/godotengine/asset-library/issues) as well as the [milestone to the 1.0 release](https://github.com/godotengine/asset-library/milestone/3) to see what is in the works. If you have issues to report or suggestions to make, please use the issue tracker.
+
+For now, enjoy the existing assets and the web frontend, and give us your feedback!
\ No newline at end of file
diff --git a/collections/_article/atlas-support-returns-godot-3-2.md b/collections/_article/atlas-support-returns-godot-3-2.md
new file mode 100644
index 0000000000..29ddbb2fc4
--- /dev/null
+++ b/collections/_article/atlas-support-returns-godot-3-2.md
@@ -0,0 +1,70 @@
+---
+title: "Atlas support returns to Godot 3.2"
+excerpt: "With the import system rewrite in Godot 3.0, the ability to import atlases was lost. Using atlases is not as common nowadays, given the processing power of desktop and devices has increased a lot, but there are many use cases where this may be worth it. Godot 3.2 will bring back support for it."
+categories: ["progress-report"]
+author: Juan Linietsky
+image: /storage/app/uploads/public/5cb/a27/5de/5cba275deeea9159968354.png
+date: 2019-04-19 00:00:00
+---
+
+With the import system rewrite in Godot 3.0, the ability to import atlases was lost. Using atlases is not as common nowadays, given the processing power of desktop and devices has increased a lot, but there are many use cases where this may be worth it. Godot 3.2 will bring back support for it.
+
+
+## What is an Atlas?
+
+Importing images into an atlas is a process that will take all of the images, and pack them into a single larger image (called an "Atlas"). Then, when the original image needs to be drawn, it actually draws the piece of the larger atlas.
+
+
+
+Character is (c) Square Enix.
+
+This is also only useful for 2D (Godot does not support 3D atlases).
+
+So, why would one use an atlas instead of individual images? In most cases, it doesn't make sense, but for some situations it may provide some improvement in memory usage or performance. Here are such cases:
+
+#### Batching
+
+In cases where a lot of objects need to be drawn, having them all share the same texture (or material) may reduce draw calls or state changes. When working on tile-sets, it's normal to have everything already drawn to a single texture but if the level uses a lot of separate images, then using an atlas may make sense to improve performance.
+
+#### Optimizing Memory
+
+When doing character animations, specially characters with hundreds of thousands of animation frames (like [Cuphead](https://youtu.be/LnIXQqldC7o?t=832)), using an atlas will not give any increase in performance (as only one frame is drawn at the same time).
+
+However, to ensure animation remains fluid and easy to integrate, animators will use a relatively large image size that remains constant, then animate a smaller character inside. This produces a lot of wasted memory, as these empty places in the animation frames take up a lot of video memory and make loading slow.
+
+
+
+
+
+
+Using atlases ensures that, before placing all the animation frames in a single image, the frames are cropped (and the offset to the crop remembered). The packer will then, ensure everything is fit in the atlas image as compactly as possible. This makes it easy to optimize for memory, as only the places in the images that contain information are saved.
+
+## How to use atlases in Godot
+
+Using atlases in Godot is _extremely_ easy. Just select all the files that you want to _pack together_ in the _Filesystem Dock_, then change the import type to "Texture Atlas".
+
+When the new file type is selected, change the "atlas file" setting to the image you will want to create, then push the "Re-Import" button. All your assets will be re-imported and added to an atlas. (The editor will restart afterwards, as the images may be in use, to ensure everything is re-opened in a clean state).
+
+Here is a visual explanation:
+
+
+
+Packing is also deterministic, which means that the same image should always be generated (this ensures it works for generating normal map atlases separatedly, as an example).
+
+## Import modes
+
+As you may have noticed, atlas files have an Import Mode, settings. There are two possible ones:
+
+#### Region
+
+This packs the used part of the image in a square region in the atlas, then this is referenced in an *AtlasTexture*.
+_Region_ takes up more space, but allows drawing only parts of the image, clipping it, etc. It also means that it can be batches. This mode is ideal for optimizing performance, as mentioned above.
+
+#### Mesh2D
+
+This cuts a polygon around the used part and packs it, resulting in considerably more efficient packing. The downside is that drawing it is less flexible (some operations such as showing a region of it are not possible). It is not possible to batch meshes either. This mode is ideal for optimizing memory in the mode mentioned before.
+
+## Future
+
+I hope this is the last feature I will personally add to Godot 3.2, so I can soon move to work on Vulkan.
+As always, if you are not yet, please consider [becoming our patron](https://www.patreon.com/godotengine), help us hire an extra developer and ensure that Godot development remains free.
\ No newline at end of file
diff --git a/collections/_article/basic-cryptography-ssl-improvements.md b/collections/_article/basic-cryptography-ssl-improvements.md
new file mode 100644
index 0000000000..b107276845
--- /dev/null
+++ b/collections/_article/basic-cryptography-ssl-improvements.md
@@ -0,0 +1,153 @@
+---
+title: "Basic cryptography, SSL improvements"
+excerpt: "As part of the MOSS project sponsored by Mozilla, during July I worked on some new features regarding cryptography and SSL to improve the quality and security of Godot networking."
+categories: ["progress-report"]
+author: Fabio Alessandrelli
+image: /storage/app/uploads/public/5d8/f4b/b0a/5d8f4bb0a3174096196968.png
+date: 2019-09-28 12:15:00
+---
+
+As part of the MOSS project sponsored by Mozilla, during July I worked on some new features regarding cryptography and SSL to improve the quality and security of Godot networking.
+
+Certificates and keys as resources
+----------------------------------
+
+SSL certificates (in the form of `*.crt` files) and private keys (in the form of `*.key` files) are now treated as resources in Godot. This means they will be exported automatically and they can be loaded via the GDScript `load()` function.
+
+Crypto class
+------------
+
+A new [`Crypto`](http://docs.godotengine.org/en/latest/classes/class_crypto.html) class was introduced that allows to access some basic cryptographic functions.
+
+- You can generate cryptographically secure random bytes via the `generate_random_bytes()` function. The bytes are returned in a `PoolByteArray`.
+- You can generate RSA keys that can be used by `StreamPeerSSL` to act as a server.
+- You can generate SSL self-signed certificates that again, can be used by `StreamPeerSSL` to act as a server.
+
+Hashing Context
+---------------
+
+A new [`HashingContext`](http://docs.godotengine.org/en/latest/classes/class_hashingcontext.html) class now provides an interface for computing cryptographic hashes (MD5, SHA-1, SHA-256) over multiple iterations.
+
+This is useful for example when computing hashes of big files (so you don't have to load them all in memory), network streams, and data streams in general (so you don't have to hold buffers). Here is an example of how it works:
+
+```
+const CHUNK_SIZE = 1024
+
+func hash_file(path):
+ var ctx = HashingContext.new()
+ var file = File.new()
+ # Start a SHA-256 context.
+ ctx.start(HashingContext.HASH_SHA256)
+ # Check that file exists.
+ if not file.file_exists(path):
+ return
+ # Open the file to hash.
+ file.open(path, File.READ)
+ # Update the context after reading each chunk.
+ while not file.eof_reached():
+ ctx.update(file.get_buffer(CHUNK_SIZE))
+ # Get the computed hash.
+ var res = ctx.finish()
+ # Print the result as hex string and array.
+ printt(res.hex_encode(), Array(res))
+```
+
+SSL improvements
+----------------
+
+[`StreamPeerSSL`](http://docs.godotengine.org/en/latest/classes/class_streampeerssl.html) can now use a per-object SSL certificate (i.e. you no longer have to set the trusted certificates om project settings), you can specify the valid certificate by passing an `X509Certificate ` as last parameter in `connect_to_stream()`.
+
+`StreamPeerSSL` can now act as a server. The new `accept_stream()` function, which accepts a private key, a certificate, and an optional CA chain, will try to establish a connection with the given stream acting as a server. This will soon also allow us to support acting as a WebSocket server over TLS.
+
+Here is an example of a test HTTPS server made in GDScript... not meant to be used in production ;-)
+
+```
+extends Node
+
+# A class that represents a client accepted by our server.
+class Client extends Reference:
+ # The SSL stream of this client.
+ var ssl = StreamPeerSSL.new()
+ # Received request.
+ var recv = ""
+
+ # Set the stream for this client.
+ func set_stream(stream, key, cert):
+ ssl.blocking_handshake = false
+ ssl.accept_stream(stream, key, cert)
+
+ # Process network operations for this client.
+ func process():
+ if ssl.get_status() == StreamPeerSSL.STATUS_HANDSHAKING:
+ # Still performing handshake.
+ ssl.poll()
+ return
+ if ssl.get_status() != StreamPeerSSL.STATUS_CONNECTED:
+ # Disconnected.
+ return
+ ssl.poll()
+ # Read available bytes.
+ if ssl.get_available_bytes() > 0:
+ recv += ssl.get_data(ssl.get_available_bytes())[1].get_string_from_utf8()
+ # Send response if request is complete.
+ if recv.ends_with("\r\n\r\n"):
+ ssl.put_data(("HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n" + \
+ "Successful connection using SSL
\r\n").to_utf8()) + ssl.disconnect_from_stream() + + func is_disconnected(): + return ssl.get_status() != StreamPeerSSL.STATUS_HANDSHAKING and \ + ssl.get_status() != StreamPeerSSL.STATUS_CONNECTED + +# Our TCP server. +var _server = TCP_Server.new() +# A list of connected clients. +var _clients = [] + +# Our private key and certificate. +var _key = null +var _cert = null + +func _ready(): + var crypto = Crypto.new() + # Generate an RSA key (this should be done in a thread to avoid blocking). + _key = crypto.generate_rsa(4096) + # Generate a self signed certificate to use with our server. + _cert = crypto.generate_self_signed_certificate(_key, "CN=example.com,O=A Game Company,C=IT") + # Start listening on "*:4343". + _server.listen(4343) + +func _process(delta): + # Take new connections. + if _server.is_connection_available(): + var c = Client.new() + c.set_stream(_server.take_connection(), _key, _cert) + _clients.append(c) + + # Take note of disconnected clients. + var to_rem = [] + # Process clients and send response when done. + for c in _clients: + c.process() + if c.is_disconnected(): + to_rem.append(c) + + # Remove disconnected clients. + for c in to_rem: + _clients.erase(c) +``` + +Future work +----------- + +This has been quite a long work, and included some refactoring of the `core` code to use a single library for cryptography (mbedTLS) instead of multiple specific libraries for hashing algorithms and AES. This work will allow us to introduce support for AES encryption and more at scripting level in future versions. + +Additionally, the SSL overhaul helped a lot in developing the upcoming DTLS implementation. + +References +---------- + +- [PR refactoring the `core` crypto code](https://github.com/godotengine/godot/pull/30239) +- [PR adding Crypto class, Hashing contexts, SSL server](https://github.com/godotengine/godot/pull/29871) +- [PR adding documentation for above-mentioned additions](https://github.com/godotengine/godot/pull/32285) \ No newline at end of file diff --git a/collections/_article/become-godot-contributor-hacktoberfest-2018.md b/collections/_article/become-godot-contributor-hacktoberfest-2018.md new file mode 100644 index 0000000000..1a27aada32 --- /dev/null +++ b/collections/_article/become-godot-contributor-hacktoberfest-2018.md @@ -0,0 +1,50 @@ +--- +title: "Become a Godot contributor for Hacktoberfest 2018" +excerpt: "Hacktoberfest 2018 has started, and you can contribute to Godot to earn a T-shirt (and experience!). Digital Ocean and GitHub sponsor this event that encourages everyone to contribute to any free and open source project on GitHub, including Godot's repositories. All pull requests count, so you can work either on the engine source code or on the documentation - there are things to do for everyone!" +categories: ["news"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5bb/27f/fe8/5bb27ffe8696a709684472.png +date: 2018-10-01 20:43:47 +--- + +October arrived, and with it one of the great community events of the FOSS year, the [Hacktoberfest](https://blog.digitalocean.com/hacktoberfest-is-back-for-year-5/)! + +This event co-organized by Digital Ocean and GitHub has simple rules: contribute 5 pull requests to open source projects on GitHub, and you will get a cool T-shirt (plus eternal recognition from project maintainers and internal fame in many communities, or something close to that ;)). + +And of course, Godot being one of the GitHub-hosted projects, you can work on your Hacktoberfest milestones by contributing directly to [Godot's source code](https://github.com/godotengine/godot) or [documentation](https://github.com/godotengine/godot-docs). + +## Getting started + +First of all head to the [**Hacktoberfest 2018 website**](https://hacktoberfest.digitalocean.com/) and register with your GitHub account (if you haven't one, you'll have to [register](https://github.com/) there too). The Hacktoberfest website has plenty of resources to get you started, and tips on how to find projects that you could be interested in, so make sure to check it in depth. + +For Godot specifically, here are relevant links and tips: + +### Engine contributions + +If you want to contribute to the game engine itself by fixing bugs or implementing enhancements (note that new features would be put on hold as we are in *feature freeze* - you can still make them but you wouldn't get much feedback for now), head to the [godotengine/godot](https://github.com/godotengine/godot/) repository. Most of the code is C++, with some bits in Objective-C (iOS/macOS), Java (Android) and JavaScript (HTML5). + +This is also the place to work on the *class reference*, the documentation of all nodes available in Godot and their properties and methods. + +Here's how to get started: + +- The [*Hacktoberfest*](https://github.com/godotengine/godot/labels/Hacktoberfest) label on the [source code repository](https://github.com/godotengine/godot) lists some "newcomer-friendly" issues that you can have a look at. Note that you are not limited to those issues, you can work on anything you want - this selection is just a shortlist. +- Similarly, the [*Hero wanted!*](https://github.com/godotengine/godot/labels/hero%20wanted%21) label also has a selection of issues ready to be worked on, where project maintainers or users have done enough initial debugging to point you in the right direction (see our [recent blog post](/article/hero-wanted-31-version) about the "Hero wanted!" campaign). +- You can also browse all other issues of the code repository which are in the [*3.1 milestone*](https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.1) (our main focus currently), and especially the ones [labelled as *bug*](https://github.com/godotengine/godot/issues?q=is%3Aopen+label%3Abug+milestone%3A3.1). +- Have a look at the [contributor's documentation](http://docs.godotengine.org/en/latest/community/contributing/index.html), especially the [CONTRIBUTING.md](https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md), the [Pull Request workflow](http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html) and the [Code style guidelines](http://docs.godotengine.org/en/latest/community/contributing/code_style_guidelines.html). +- Join the [`#godotengine-devel`](http://webchat.freenode.net/?channels=#godotengine-devel) IRC channel on Freenode (also bridged on [Matrix](https://matrix.to/#/#freenode_#godotengine-devel:matrix.org)) to discuss with fellow engine contributors. + +If you want to work on the class reference, have a look at the [dedicated page](http://docs.godotengine.org/en/latest/community/contributing/updating_the_class_reference.html). + +### Documentation contributions + +To contribute to the [online documentation and tutorials](http://docs.godotengine.org/), the main repository is [godotengine/godot-docs](https://github.com/godotengine/godot-docs/). Note that as mentioned above, contributions to the [class reference](http://docs.godotengine.org/en/latest/classes/index.html) should instead be done directly in the engine repository (as the class reference is also included offline in the editor). + +Here's how to get started: + +- Check the [list of issues](https://github.com/godotengine/godot-docs/issues) and see if there's anything you'd like to work on. +- Review the documentation on [how to write documentation](http://docs.godotengine.org/en/latest/community/contributing/documentation_guidelines.html) (yes, that has to be documented too!). +- Join the `#documentation` channel on [Godot's Discord](https://discord.gg/zH7NUgz) server (most active place to discuss with fellow documentation contributors), or if you prefer the [`#godotengine-doc`](http://webchat.freenode.net/?channels=#godotengine-doc) IRC channel on Freenode (but it's less active). + +That's it! It's a lot of links and documentation, but you of course don't need to review everything in depth, look in priority at the [contributor's documentation](http://docs.godotengine.org/en/latest/community/contributing/index.html) and then pick something you'd like to work on. + +Enjoy your Hacktoberfest and have fun contributing to your very own engine! \ No newline at end of file diff --git a/collections/_article/ben-tristem-gamedevtv-are-kickstarting-godot-course.md b/collections/_article/ben-tristem-gamedevtv-are-kickstarting-godot-course.md new file mode 100644 index 0000000000..b2cf5daedb --- /dev/null +++ b/collections/_article/ben-tristem-gamedevtv-are-kickstarting-godot-course.md @@ -0,0 +1,48 @@ +--- +title: "Ben Tristem & GameDev.tv are kickstarting a Godot course" +excerpt: "Ben Tristem and his GameDev.tv team, authors of many best-selling game development courses on the online platform Udemy, are now kickstarting a Godot Engine course! +They strongly believe in Godot and want to make top quality content for all kinds of users. Ben tells us in a video what they like in Godot and why they are so enthusiastic about it." +categories: ["news"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5b0/329/342/5b032934283e8029566244.jpg +date: 2018-05-21 20:38:35 +--- + +If you are into game development, chances are that you've heard of [Ben Tristem](https://en.wikipedia.org/wiki/Ben_Tristem) and his [GameDev.tv](https://www.gamedev.tv/) team, as they are making some of the best-rated [online courses on Udemy](https://www.gamedev.tv/) for game engines like Unity3D and Unreal Engine 4, as well as art making tools like Blender and The GIMP. + +## New professional Godot course on Kickstarter + +Last week, Ben and his team started a new Kickstarter campaign for a [**Godot Engine course**](https://www.kickstarter.com/projects/bentristem/discovering-godot-learn-to-code-by-making-games?ref=7dkj1f)! + +In the Godot team, we are delighted to see them giving Godot the spotlight it deserves by making a top-quality professional course for the hundreds of thousands of Udemy users that learn with their material. + +Their formula was tested and proven on other game engines, and we can't wait to see how they will approach Godot – we are confident that they will make a great course, as they plan to involve the backers and the greater Godot community to help them shape the final curriculum. + +**Link:** [Discovering Godot – Learn to Code by Making Games](https://www.kickstarter.com/projects/bentristem/discovering-godot-learn-to-code-by-making-games?ref=7dkj1f) by Ben Tristem and Yann Burrett. + +Make sure to check it out and to support the campaign if you can, as this course should be a great learning resource as well as a visibility boost for your favourite no-marketing-budget game engine :) +You'll see all the details about the course's purpose and contents [on the Kickstarter page](https://www.kickstarter.com/projects/bentristem/discovering-godot-learn-to-code-by-making-games?ref=7dkj1f). + +
+
+## Ben tells us why they support Godot
+
+GameDev.tv had already been showing its interest in Godot by sponsoring us financially [on Patreon](https://www.patreon.com/godotengine) over the last few months, and now they show their commitment and trust by actual making their own teaching product based on Godot.
+
+> *We believe in the future of Godot, and that's the reason we've been sponsoring the project for a while. It's also the fundamental reason we're creating courses for the engine – to help support it and spread the word.*
+
+I've asked Ben to give us some details about what they see in Godot, and why they are so enthusiastic about it and willing to give it a top-tier position among their game development courses:
+
+
+
+> *We're big fans of Godot's:*
+>
+> - *Language flexibility*
+> - *Separate 2D and 3D pipelines*
+> - *Open source(ness), allowing users to modify and even contribute*
+>
+> *And it's fun! It's fun to use, it's simple when you open it, it's powerful if you need it, it unfolds the complexity as and when you require it. We find that so inviting!*
+
+These points really echo what we hear on all [Godot community channels](https://godotengine.org/community), where users really enjoy the flexibility offered by Godot's design and license, and simply have a lot of fun experimenting and working on long term projects alike.
+
+If you want to communicate directly with Ben, Yann and other users waiting for this course, you can join GameDev.tv's [Facebook group dedicated to the Godot course](https://www.facebook.com/groups/godotcourse/).
\ No newline at end of file
diff --git a/collections/_article/beta-release-python-support.md b/collections/_article/beta-release-python-support.md
new file mode 100644
index 0000000000..601b06a300
--- /dev/null
+++ b/collections/_article/beta-release-python-support.md
@@ -0,0 +1,37 @@
+---
+title: "Beta release for Python support"
+excerpt: "Emmanuel Leblond (touilleMan) just released the first beta of his Python for Godot interface, which will allow developers to use Python 3 and its complete ecosystem as a scripting language in Godot 3.0."
+categories: ["news"]
+author: Rémi Verschelde
+image: /storage/app/uploads/public/596/62b/1c4/59662b1c4ffa8859295653.png
+date: 2017-07-12 08:59:44
+---
+
+*This is a guest post by Emmanuel Leblond (touilleMan), a Godot contributor and Python lover who develops a GDNative interface to use Python 3 as alternative scripting language in Godot. To answer the obligatory question: yes, the plan is still to ship Godot 3.0 with GDScript, VisualScript and C# support. Python support should also be ready by then and usable plug 'n play thanks to GDNative; its main advantage compared to the Python-like GDScript will be the access to the whole Python ecosystem.*
+
+------
+
+Who said Godot's only about waiting? Today we are releasing the [first beta version of Python for Godot](https://github.com/touilleMan/godot-python), the GDNative interface that enables you to use the full-blown Python 3 as a scripting language for Godot games. Now we need you to try it and give your feedback, so that it can be made as good as possible for the upcoming 3.0 release!
+
+- [Release 0.9.0 page](https://github.com/touilleMan/godot-python/releases/tag/v0.9.0)
+- [Direct link to 0.9.0 linux binary release](https://github.com/touilleMan/godot-python/releases/download/v0.9.0/godot-python-0.9.0.tar.bz2)
+- [Repository for Godot Python](https://github.com/touilleMan/godot-python)
+
+All core features of Godot are expected to work fine:
+
+- Builtins (e.g. `Vector2`)
+- Object classes (e.g. `Node`)
+- Signals
+- Variable export
+- RPC synchronization
+
+On top of that, mixing GDScript and Python code inside a project should work fine, have a look at the [Pong example](https://github.com/touilleMan/godot-python/tree/master/examples/pong) to see how you can convert one by one your existing GDScript code to Python fairly easily.
+
+This release ships a recent build of Godot 3.0-alpha (yes, it's a beta based on an alpha...) and CPython 3.6.1 with the standard library and pip, ready to work with the Python ecosystem in its full glory (can't wait to see people experimenting game AI with [Pytorch](http://pytorch.org/)!).
+
+The project is Linux-only so far, however you should be able to compile it from the sources if you are on macOS (let us know if you do so).
+Binaries for all platforms will eventually be provided when Godot 3.0 gets stable.
+
+As always, keep in mind this is a beta and you are expected to encounter issues and maybe crashes. If so, make sure to report them on the [project's bug tracker](https://github.com/touilleMan/godot-python/issues) ;-)
+
+**PS:** A talk about Godot & Python was given last Monday at [EuroPython 2017](https://ep2017.europython.eu/conference/talks/bringing-python-to-godot-game-engine). You can watch the (for now unedited) recording [on YouTube](https://www.youtube.com/watch?v=h6MsqsJqnao&feature=youtu.be&t=2h35m09s); the edited version should be available later on [EuroPython's YouTube channel](https://www.youtube.com/c/EuroPythonConference).
\ No newline at end of file
diff --git a/collections/_article/betsy-gpu-texture-compressor.md b/collections/_article/betsy-gpu-texture-compressor.md
new file mode 100644
index 0000000000..9c2e2e13c0
--- /dev/null
+++ b/collections/_article/betsy-gpu-texture-compressor.md
@@ -0,0 +1,328 @@
+---
+title: "Introducing the Betsy GPU texture compressor"
+excerpt: "My name is Matias N. Goldberg, I normally maintain the 2.x branch of Ogre, and I wrote Betsy, a GPU texture compressor that runs on GPUs."
+categories: ["progress-report"]
+author: Matias Goldberg
+image: /storage/app/uploads/public/5fb/e92/016/5fbe920160a53834592537.jpg
+date: 2020-11-25 00:00:00
+---
+
+My name is [Matias N. Goldberg](https://twitter.com/matiasgoldberg), I normally maintain the [2.x branch of Ogre](https://www.ogre3d.org/download/sdk/sdk-ogre-next) aka [ogre-next](https://github.com/OGRECave/ogre-next) and I wrote Betsy, a GPU texture compressor that runs on GPUs.
+
+This work was commissioned by Godot Engine through the Software Freedom Conservancy to solve a major complaint: importing textures is excruciantly slow and takes many minutes.
+
+Certain compression algorithms such as BC1-5 are quite simple and there are already fast high quality compression algorithms.
+
+However algorithms such as BC6, ETC1, ETC2 and EAC are currently taking the majority of time and thus considerably attention were given to these.
+
+Nonetheless Betsy implemented compute-shader versions for BC1,3,4,5,6, ETC1,2 and EAC algorithms.
+
+Betsy works as a standard Command Line tool which means it can be used like any other exe tool outside of Godot.
+
+More importantly, Betsy was developed with integration to Godot in mind, which is why its code has been isolated and abstracted from API details, written in GLSL shaders since Godot uses Vulkan.
+
+Godot can make further performance improvements a standard CLI tool can't, because Godot doesn't have to initialize the graphics API every time it is invoked to compress a texture; and Godot can upload a texture just once and then encode into multiple formats (e.g. compress into BC1 and ETC1, or EAC and BC4 at the same time); rather than re-upload the texture again for every format we need to compress into.
+
+Theoretically the CLI tool could accept to encode many textures in a single invocation (e.g. encode A.png into A.etc1.ktx A.etc2.ktx A.bc1.ktx and B.etc1.ktx B.etc2.ktx B.bc1.ktx) but we were worried that could complicate the code and make its integration with Godot harder. Additionally it's hard to write a generic tool interface that would take advantage of such command line syntax.
+
+# What is texture compression and why you care
+
+GPUs have precious limited available RAM. Too many big textures and you can see yourself running out of RAM.
+
+When that happens, the GPU driver may fallback to streaming from regular system RAM over the PCI-E bus.
+
+When this works, a significant performance degradation can happen.
+When this doesn't, the game will just crash.
+
+On phones, lower RAM consumption isn't the only reason. Smaller textures mean less bandwidth. And less bandwidth means better battery life (and sometimes less bandwidth can also mean higher performance on both desktop and mobile).
+
+There are three major types of texture compression categories, but only one is useful for GPUs:
+
+## Lossless (e.g. PNG)
+
+This compression family lower the size of the texture using algorithms such as [gzip](https://en.wikipedia.org/wiki/Gzip), [bzip](https://en.wikipedia.org/wiki/Bzip2) or [LZMA](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm), among others. The main advantage is that the bits of the original texture are preserved. That's why it's **loss**-**less** i.e. no quality is lost.
+
+The disadvantage is that they take a variable time to decompress i.e. it can take anywhere as 1 nanosecond to 30 seconds, or who knows, maybe more.
+
+Unfortunately, due to this variable-time in decompression, these family of texture compression algorithms are of no use for a GPU.
+
+Another disadvantage is that the compression ratio is unknown. A 1024x1024 may compress to 10kb, while another 1024x1024 texture may compress to 0.7MB.
+
+This large unknown disparity in size also makes them inviable for GPUs.
+
+This means that a 1024x1024 RGBA PNG texture that is only 10kb on disk **must** be decompressed before uploading to the GPU, thus always occupying 4MB of video RAM.
+
+## Lossy (e.g. JPEG)
+
+This compression family uses algorithms like [Discrete Cosine Transform](https://en.wikipedia.org/wiki/Discrete_cosine_transform) (aka DCT) to discard some details of the original image in order to hugely reduce their size.
+
+That is: they do lose quality, but it is often hard to notice and achieve huge size reductions.
+
+Unfortunately, they're still a no-go for GPUs due to how expensive it is to decode DCT, and because decompressing often requires 'postprocessing' passes that looks on the whole texture to hide artifacts and improve quality.
+
+Therefore, just like in the PNG case, a 1024x1024 RGB JPEG texture that is only 120kb on disk **must** be decompressed before uploading to the GPU, thus always occupying 4MB of video RAM.
+
+## GPU lossy (e.g. BC1-7, ETC1-2, EAC, PVRTC, ASTC)
+
+We finally arrive at the family this article is about!
+
+This family of compression algorithms meet two criterias that are *key* for GPUs:
+
+ 1. Decompression is fast and easy, and can be done in constant O(1) time. i.e. it always takes the same amount of time. e.g. if it takes 20 nanoseconds on a given GPU, it *always* takes 20 nanoseconds, no matter which pixel you need to fetch.
+ 2. Compression ratio is constant. For example BC1 has a 1:8 compression ratio. That means that a 1024x1024 RGB texture which on RAM would occupy 4MB uncompressed, using BC1 it will *always* occupy 0.5MB
+
+**To be clear:** except rare occassions, these formats cannot compete in quality against the other family of lossy formats (like JPEG), and they do not intend to.
+
+Fast decompression and reasonable quality are the goals here. If you don't like it and have infinite money, you can always buy a 24GB RAM GPU.
+
+But for the rest of us, this compression family is a good deal.
+
+**Why are there so many formats (BC1, BC4, ETC1, etc, etc) you ask?**
+
+Well, one reason is patents. For example ETC1, ETC2 and EAC appeared because phone vendors didn't want to pay the patent for the BC1-5 family of compression algorithms. This patent [expired on March 16, 2018](https://en.wikipedia.org/wiki/S3_Texture_Compression#Patent). However plenty of phones came before 2018.
+
+Another reason is that some algorithms are better suited for different content. For example BC5 & EAC are very good at compressing *normal maps*, while BC1 & ETC1 are reasonably good for compressing RGB *photo-like* textures, and BC3 and ETC2 are reasonably good for RGBA photo-like textures.
+
+Then some formats simply are improvements over time: BC7 came *much* later and is BC1 on steroids. Although it is double the size of BC1, it preserves quality much better than BC1 ever did. If your card supports DirectX10, then it supports BC7. But if it's older than that, it won't.
+
+Then there is the relatively-new ASTC which is a very good and flexible patent-free compression format, but desktop vendors resist it because it is very expensive in terms of HW manufacturing costs and die area size. Also not all phones support it, either because they're too old, or due to costs.
+
+# GPU compression can take (a lot of) time
+
+OK, so we just have to use those formats I mentioned above right? We use BC1, BC3, ETC1, etc.
+
+Hold on! Not so fast:
+
+Some GPUs support some textures but not others. While there are assumptions that can be made (e.g. all desktop DX10-class GPUs and newer support BC1-7), if you aim at different platforms (Windows, iOS, Android) the answer to the question '*which format should we use?*' then the answer will be: **All of them**.
+
+Games usually have to bundle the same textures in all suitable formats and pick the best supported variation based on the HW it is running.
+
+This isn't good for package sizes on disk, but we ensure compatibility. Some mobile games decide to download the texture pack after installation once it knows which device it is running on.
+
+Other solutions like [Basis Universal](https://github.com/BinomialLLC/basis_universal) use the term 'transcoding' to generate an ETC1 or BC1 texture based on a single binary package. By trading off some quality and saving shared information, an ETC1 or BC1 texture can be generated on the fly.
+
+The main problem is that some formats like BC1 are easy to encode. **But other formats like ETC2 or BC7 can take a lot of time**. Encoding a bunch of small textures can take literal minutes!
+
+If an artist needs to wait 30 seconds to deploy to his phone every time he changes a few textures to see how it looks like, then we've got a big iteration problem!
+
+That's where betsy comes in.
+
+# Not all encoders are born equal
+
+Performance isn't the only metric! Another issue is that not all compressors produce the same quality!
+
+There are many ways to encode a texture, and arriving to each solution will achieve slightly different results. Some compressors are better at preserving quality than others.
+
+Betsy aims at encoding in high quality. Even if we may not end up being *the* best encoder, we can't sacrifice quality for speed (unless it's configurable and the user wants to)
+
+# Betsy is a GPU encoder
+
+Regular code is written to be run on a CPU. Betsy runs on a GPU.
+GPUs are massively parallel machines. And GPU compression happens to parallelize quite well (some formats better than others)
+
+What is faster depends on what CPU do you own vs what GPU do you own, and which compression format is selected.
+A 64-core Ryzen Threadripper paired with a GeForce 1030 or Radeon HD 7350, the CPU will obviously beat the GPU.
+
+However if you own the latest GeForce 3080 or Radeon 6800 XT, chances are a GPU encoder will win in encoding time.
+
+It is important to mention that my work was mostly porting existing codecs written in C or C++ for the CPU, and convert them into GPU-friendly compute shaders. A notable exception is ETC2's P-mode which has been extended with our own efforts to significantly improve encoding quality of this mode.
+
+You can find more information in the [LICENSE](https://github.com/darksylinc/betsy/blob/master/LICENSE.md) and [README](https://github.com/darksylinc/betsy/blob/master/README.md) pages.
+
+# Benchmark Performance
+
+OK enough boring explanation! Let's see how Betsy fares against other encoders:
+
+Notes:
+
+ 1. CPU is Intel i7 7700 3.6Ghz (4.2Ghz turbo). 2x16GB RAM 3000Mhz. 4 core, 8 threads.
+ 1. GPU is AMD Radeon HD 560 2GB VRAM
+ 1. Benchmark was done on Linux Ubuntu 18.04 LTS (HWE), Mesa 20.1.3
+ 1. [etc2comp](https://github.com/google/etc2comp) is what Godot currently uses
+ 1. [ConvectionKernels](https://github.com/elasota/ConvectionKernels) aka CVTT, which uses SIMD/SSE to run compress multiple blocks at once, similarly to what Betsy does.
+ 1. Multithreaded tests were done spawning one process for each texture. This is suboptimal as it results in oversubscription for CVTT, and excessive contention of access to GPU for Betsy. The exception is etc2comp which supports native per-texture multithreading out of the box.
+ 1. Single threaded numbers for CVTT are included because multithreading is not supported out of the box by CVTT
+ 1. Single threaded numbers for etc2comp are not included because it supports multithreading out of the box, and single threaded version is simply way too slow.
+ 1. The original Kodim set's resolution was too small to fully saturate the GPU in Betsy (according to radentop, around 60% GPU usage), which is why there is a strong difference between the 'multithreaded' and 'singlethreaded' versions. This difference gets much smaller for the 2048 upscaled set (keeping aspect ratio).
+ 1. Betsy was run for every texture independently, which includes a small overhead for initializing OpenGL every time. This could be further improved to support encoding multiple textures with one single invocation.
+ 1. Betsy's first run in a system may take considerably larger time as compute shaders must be compiled and will later be cached by the driver in subsequent runs. This will happen again if the driver is updated.
+ 1. All values are time in seconds.
+ 1. Betsy's Quality = 1 (medium quality) was included because it only affects ETC1 modes (not the extended T, H and P ETC2 modes), the quality difference is very low, but the performance gains are gigantic.
+ 1. The scripts used to run this benchmark can be found on [Github/betsy_benchmark](https://github.com/darksylinc/betsy_benchmark)
+
+## ETC1
+
+| Set | **Betsy MT (q = 1)** | **Betsy ST (q = 2)** | **Betsy MT (q = 2)** | **CVTT ST** | **CVTT MT** | **etc2comp MT** |
+| ---------------------------- | -------------------- | -------------------- | -------------------- | ----------- | ----------- | --------------- |
+| Kodim (25 textures) | 1,36 | 11,45 | 9,01 | 34,88 | 6,85 | 18,35 |
+| Upscaled to 2048xN Kodim | 3,6 | 56,95 | 52,72 | 244,14 | 48,29 | 138,5 |
+
+## ETC2 RGB
+
+| Set | **Betsy MT (q = 1)** | **Betsy ST (q = 2)** | **Betsy MT (q = 2)** | **CVTT ST** | **CVTT MT** | **etc2comp MT** |
+| ---------------------------- | -------------------- | -------------------- | -------------------- | ----------- | ----------- | --------------- |
+| Kodim (25 textures) | 3,16 | 13,21 | 10,85 | 45,44 | 8,16 | 39,29 |
+| Upscaled to 2048xN Kodim | 14,68 | 69,55 | 65,41 | 322,26 | 57,81 | 253,48 |
+
+## BC1
+
+| Set | **Betsy ST** | **Betsy MT** | **nvcompress ST (CPU)** | **nvcompress MT (CPU)** |
+| ---------------------------- | ------------ | ------------ | ----------------------- | ----------------------- |
+| Kodim (25 textures) | 3,12 | 0,6 | 12,6 | 2,4 |
+| Upscaled to 2048xN Kodim | 4,87 | 1,34 | 85,07 | 16,17 |
+
+*Notes:*
+
+ 1. *This needs more research, but it appears BC1 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time*
+ 1. *CVTT supports BC1, however its CLI tool doesn't come with BC1 support out of the box and I had no time to add support for it to do the benchmark*
+
+## BC5
+
+| | **Betsy ST** | **Betsy MT** | **nvcompress ST (CPU)** | **nvcompress MT (CPU)** |
+| ---------------------------- | ------------ | ------------ | ----------------------- | ----------------------- |
+| Kodim set (25 textures) | 2,94 | 0,73 | 1,97 | 0,42 |
+| Upscaled to 2048xN Kodim set | 5,84 | 1,70 | 13,18 | 0,86 |
+
+*Notes:*
+
+ 1. *This needs more research, but it appears BC5 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time*
+ 1. *CVTT supports BC5, however its CLI tool doesn't come with BC5 support out of the box and I had no time to add support for it to do the benchmark*
+
+# Benchmark quality
+
+Notes:
+
+ 1. RSMLE: **Lower is better**. It means Root Mean Squared Logarithmic Error.
+ 1. Betsy q = 1 is medium quality
+ 1. Betsy q = 2 is maximum quality
+ 1. It is unknown why ConvectionKernels some RSMLE increased in ETC2 over ETC1. It could be a CVTT bug, or a difference in how CVTT measures error vs how I measured it.
+
+## ETC1 RGB
+
+| | Betsy (q = 1) | Betsy (q = 2) | ConvectionKernels | etc2comp |
+| ----------- | ------------- | ------------- | ----------------- | -------- |
+| **Average** | **0.0244532** | **0.02389376**| **0.02383864** | **0.02502284** |
+| kodim01.png | 0.027957 | 0.027166 | 0.026895 | 0.028578 |
+| kodim02.png | 0.021755 | 0.021433 | 0.021336 | 0.021954 |
+| kodim03.png | 0.019651 | 0.019205 | 0.01924 | 0.019886 |
+| kodim04.png | 0.021453 | 0.021123 | 0.020989 | 0.021704 |
+| kodim05.png | 0.033579 | 0.032763 | 0.032588 | 0.034686 |
+| kodim06.png | 0.024893 | 0.024265 | 0.024038 | 0.02545 |
+| kodim07.png | 0.021911 | 0.021344 | 0.021057 | 0.022076 |
+| kodim08.png | 0.032968 | 0.032022 | 0.031604 | 0.034042 |
+| kodim09.png | 0.02002 | 0.019602 | 0.01945 | 0.020201 |
+| kodim10.png | 0.01986 | 0.019409 | 0.019306 | 0.020063 |
+| kodim11.png | 0.023587 | 0.023122 | 0.022928 | 0.024056 |
+| kodim12.png | 0.018662 | 0.018255 | 0.018087 | 0.018833 |
+| kodim13.png | 0.035328 | 0.034559 | 0.034416 | 0.036992 |
+| kodim14.png | 0.030336 | 0.029845 | 0.029985 | 0.030972 |
+| kodim15.png | 0.02186 | 0.021373 | 0.021296 | 0.02207 |
+| kodim16.png | 0.019238 | 0.018806 | 0.018663 | 0.019542 |
+| kodim17.png | 0.020262 | 0.019792 | 0.019767 | 0.020738 |
+| kodim18.png | 0.027783 | 0.02724 | 0.02728 | 0.028719 |
+| kodim19.png | 0.023358 | 0.022718 | 0.022477 | 0.023831 |
+| kodim20.png | 0.019751 | 0.019281 | 0.019395 | 0.020377 |
+| kodim21.png | 0.025063 | 0.024488 | 0.024325 | 0.025592 |
+| kodim22.png | 0.02337 | 0.022873 | 0.023036 | 0.023909 |
+| kodim23.png | 0.020536 | 0.020071 | 0.020435 | 0.021016 |
+| kodim24.png | 0.028179 | 0.027181 | 0.028165 | 0.029515 |
+| kodim25.png | 0.02997 | 0.029408 | 0.029208 | 0.030769 |
+
+## ETC2 RGB
+
+| | Betsy (q = 1) | Betsy (q = 2) | ConvectionKernels | etc2comp |
+| ----------- | ------------- | ------------- | ----------------- | -------- |
+| **Average** | **0.02432348**| **0.02378536**| **0.02400548** | **0.02412212** |
+| kodim01.png | 0.027986 | 0.027183 | 0.027318 | 0.027943 |
+| kodim02.png | 0.021448 | 0.021169 | 0.020991 | 0.020887 |
+| kodim03.png | 0.019842 | 0.019471 | 0.018829 | 0.018195 |
+| kodim04.png | 0.021408 | 0.021105 | 0.020959 | 0.020991 |
+| kodim05.png | 0.03355 | 0.032722 | 0.033068 | 0.033774 |
+| kodim06.png | 0.02492 | 0.024283 | 0.024317 | 0.024731 |
+| kodim07.png | 0.02115 | 0.020651 | 0.020834 | 0.020812 |
+| kodim08.png | 0.033198 | 0.032233 | 0.03278 | 0.033356 |
+| kodim09.png | 0.019712 | 0.019335 | 0.019633 | 0.01955 |
+| kodim10.png | 0.019716 | 0.019285 | 0.019424 | 0.019459 |
+| kodim11.png | 0.023473 | 0.022995 | 0.023223 | 0.023395 |
+| kodim12.png | 0.018597 | 0.018215 | 0.018109 | 0.017998 |
+| kodim13.png | 0.03541 | 0.034635 | 0.035375 | 0.036008 |
+| kodim14.png | 0.030282 | 0.029791 | 0.029887 | 0.029976 |
+| kodim15.png | 0.021945 | 0.021515 | 0.021449 | 0.021243 |
+| kodim16.png | 0.01877 | 0.018382 | 0.01866 | 0.018717 |
+| kodim17.png | 0.020175 | 0.019729 | 0.019988 | 0.019844 |
+| kodim18.png | 0.028034 | 0.027471 | 0.027707 | 0.02808 |
+| kodim19.png | 0.023166 | 0.022545 | 0.022932 | 0.023125 |
+| kodim20.png | 0.019773 | 0.019299 | 0.019545 | 0.019642 |
+| kodim21.png | 0.02487 | 0.024313 | 0.024721 | 0.024833 |
+| kodim22.png | 0.02336 | 0.022859 | 0.023109 | 0.02323 |
+| kodim23.png | 0.019306 | 0.018971 | 0.019284 | 0.018592 |
+| kodim24.png | 0.028032 | 0.027072 | 0.02846 | 0.028448 |
+| kodim25.png | 0.029964 | 0.029405 | 0.029535 | 0.030224 |
+
+## BC1
+
+| | **Betsy** | **nvcompress** |
+| ----------- | ------------ | -------------- |
+| **Average** | **0.028589** | **0.026943** |
+| kodim01.png | 0.034792 | 0.032564 |
+| kodim02.png | 0.02562 | 0.024146 |
+| kodim03.png | 0.020277 | 0.018898 |
+| kodim04.png | 0.023814 | 0.022424 |
+| kodim05.png | 0.040001 | 0.037991 |
+| kodim06.png | 0.0298 | 0.028163 |
+| kodim07.png | 0.024172 | 0.022762 |
+| kodim08.png | 0.042638 | 0.040288 |
+| kodim09.png | 0.022284 | 0.020803 |
+| kodim10.png | 0.022031 | 0.020619 |
+| kodim11.png | 0.028216 | 0.026493 |
+| kodim12.png | 0.020243 | 0.01892 |
+| kodim13.png | 0.045498 | 0.042873 |
+| kodim14.png | 0.034357 | 0.032726 |
+| kodim15.png | 0.024274 | 0.023026 |
+| kodim16.png | 0.021505 | 0.019977 |
+| kodim17.png | 0.023141 | 0.021715 |
+| kodim18.png | 0.033236 | 0.031521 |
+| kodim19.png | 0.027642 | 0.025856 |
+| kodim20.png | 0.02268 | 0.021438 |
+| kodim21.png | 0.029862 | 0.028107 |
+| kodim22.png | 0.026809 | 0.02531 |
+| kodim23.png | 0.020595 | 0.019312 |
+| kodim24.png | 0.034883 | 0.033199 |
+| kodim25.png | 0.036355 | 0.034444 |
+
+## BC5
+
+| | **Betsy** | **nvcompress** |
+| ----------- | -------------- | -------------- |
+| **Average** | **0,40713988** | **0,4071152** |
+| kodim01.png | 0,380992 | 0,380943 |
+| kodim02.png | 0,147688 | 0,147673 |
+| kodim03.png | 0,341727 | 0,341719 |
+| kodim04.png | 0,35518 | 0,355176 |
+| kodim05.png | 0,317971 | 0,317893 |
+| kodim06.png | 0,467379 | 0,467362 |
+| kodim07.png | 0,368736 | 0,368721 |
+| kodim08.png | 0,507863 | 0,507801 |
+| kodim09.png | 0,511146 | 0,511134 |
+| kodim10.png | 0,482672 | 0,482662 |
+| kodim11.png | 0,364467 | 0,364442 |
+| kodim12.png | 0,570088 | 0,570084 |
+| kodim13.png | 0,388023 | 0,387951 |
+| kodim14.png | 0,313848 | 0,313811 |
+| kodim15.png | 0,495639 | 0,49563 |
+| kodim16.png | 0,404634 | 0,404633 |
+| kodim17.png | 0,329696 | 0,329685 |
+| kodim18.png | 0,229002 | 0,228954 |
+| kodim19.png | 0,424489 | 0,424464 |
+| kodim20.png | 0,70348 | 0,703468 |
+| kodim21.png | 0,487161 | 0,487138 |
+| kodim22.png | 0,393033 | 0,393022 |
+| kodim23.png | 0,364163 | 0,364154 |
+| kodim24.png | 0,424539 | 0,424513 |
+| kodim25.png | 0,404881 | 0,404847 |
+
+# Get Technical
+
+If you're a GPU nerd, we have an [in-depth analysis](https://github.com/darksylinc/betsy/blob/master/Docs/technical_doc_advanced.md) of how betsy's compute shaders are implemented.
+
+Keep in mind it is quite advanced and assumes you're somewhat familiar with GPU shader coding.
\ No newline at end of file
diff --git a/collections/_article/bugs-lets-catch-em-all-saturday.md b/collections/_article/bugs-lets-catch-em-all-saturday.md
new file mode 100644
index 0000000000..de5aad5a49
--- /dev/null
+++ b/collections/_article/bugs-lets-catch-em-all-saturday.md
@@ -0,0 +1,35 @@
+---
+title: "Bugs: Let's catch 'em all this Saturday 9 December"
+excerpt: "Both testers and developers are doing a great job, but we need to go ever faster to get Godot 3.0 out as soon as possible - especially now that the master branch is in feature freeze, meaning that new features will have to wait for Godot 3.1 to be merged.
+
+We propose to have a special bug hunting day on Saturday, 9 December, to focus on fixing the bugs reported for the 3.0 milestone. Testers are also encouraged to use this opportunity to file new bug reports, after checking existing issues for potential duplicates."
+categories: ["events"]
+author: Rémi Verschelde
+image: /storage/app/uploads/public/5a2/add/15e/5a2add15ea3c5631753661.png
+date: 2017-12-08 19:02:08
+---
+
+Since our [Godot 3.0 beta 1](/article/dev-snapshot-godot-3-0-beta-1) release last week, there have been [more than 70 bugs fixed](https://github.com/godotengine/godot/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+closed%3A2017-11-29..2017-12-08+-label%3Aarchived) and over 100 bug reports created!
+
+Both testers and developers are doing a great job, but we need to go ever faster to get Godot 3.0 out as soon as possible - especially now that the *master* branch is in feature freeze, meaning that new features will have to wait for Godot 3.1 to be merged.
+
+## Bug hunting day on Saturday 9 December
+
+We propose to have a special bug hunting day tomorrow (Saturday 9 December), to focus on fixing the bugs reported for the 3.0 milestone. Testers are also encouraged to use this opportunity to file new bug reports, after checking existing issues for potential duplicates.
+
+### How does it work?
+
+Join us on the developers' IRC channel ([#godotengine-devel](http://webchat.freenode.net/?channels=#godotengine-devel) on Freenode, also accessible from Matrix) to discuss issues and potential fixes live, and pick any bug in the [3.0 milestone](https://github.com/godotengine/godot/milestone/4) to try to fix it. To avoid potential conflicts/duplicated work, add a comment in the relevant issue to state that you are working on it.
+
+If you don't know which issue to start with, check the [Hero Wanted!](https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3A%22hero+wanted%21%22) selection which lists bugs with useful debugging information and/or some hints about how to fix them.
+
+The event will start as soon as someone is awake in the channel on Saturday (our contributors from Asia and Australia will get to start :)), and will continue for the whole day over the globe's timezones.
+
+You're free to join for one hour or for the whole day, the important is that we fix issues and get to know each other at the same time. There should always be plenty of experienced devs around to help you get started if you are not very familiar with Godot's source code.
+
+### Links
+
+- [List of issues in the 3.0 milestone](https://github.com/godotengine/godot/milestone/4) (meant to be fixed before 3.0 is released, or eventually moved to the next milestone if non critical).
+- [List of "Hero Wanted!" issues](https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3A%22hero+wanted%21%22).
+- [Contributing docs](http://docs.godotengine.org/en/latest/community/contributing/ways_to_contribute.html), especially the parts of the [PR workflow](http://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html) and the [code style guidelines](http://docs.godotengine.org/en/latest/community/contributing/code_style_guidelines.html).
+- [#godotengine-devel on Freenode](http://webchat.freenode.net/?channels=#godotengine-devel)
\ No newline at end of file
diff --git a/collections/_article/call-for-participation-online-godotcon-2021.md b/collections/_article/call-for-participation-online-godotcon-2021.md
new file mode 100644
index 0000000000..11dda70a8b
--- /dev/null
+++ b/collections/_article/call-for-participation-online-godotcon-2021.md
@@ -0,0 +1,53 @@
+---
+title: "Call for participation to Online GodotCon 2021"
+excerpt: "Given the international situation, we are going online for our next Godot conference in 2021! Online GodotCon 2021 will happen on the 23rd of January 2021, with pre-recorded talks and then live Q&As with the speakers, as well as a dedicated chat platform for attendees to socialize together. We're now asking all interested users to send us proposals for talks, demos, etc. for the event."
+categories: ["events"]
+author: Julian Murgia
+image: /storage/app/uploads/public/5fc/8f2/85e/5fc8f285e75a5623838507.png
+date: 2020-12-03 14:25:37
+---
+
+2021 is quickly approaching and in the Godot community we are starting to prepare for next year's GodotCon!
+
+As you might know, each year we attend FOSDEM, the major Free and Open Source event in Europe, and we use the opportunity to organise our own small conference as a fringe event: GodotCon! A meetup for contributors, users and interested people to socialize, collaborate and share knowledge.
+
+Sadly, given the uncertainty regarding international travel and the possibility to host big gatherings, FOSDEM has decided to go online-only for next year's edition and we are taking the same decision for our own GodotCon.
+
+It's not all bad news because as much as we'll miss meeting each other in person, we must see it as an opportunity for everyone to participate, no matter where they are located.
+
+# So, what's the plan?
+
+**Online GodotCon 2021** will happen on the **23rd of January** (the weekend before the Global Game Jam ;)) and will consist of a video stream with pre-recorded talks and a community platform to host chat and Q&A.
+
+We decided to go for pre-recorded event as this will be our first fully online event and we would like to simplify its technical complexity so everyone has the best experience. This will also make it more comfortable for users to present if GodotCon is happening at an impractical time for their timezone.
+
+We are preparing a way for users to submit questions for the presenter to answer, we will share more info on this topic closer to the event.
+
+As usual for Godot events, Online GodotCon 2021 will be **free of charge**, and the video streams will be available to replay after the event. More precise details on the streaming and chat platforms, as well as start and end time, will be announced in coming weeks.
+
+# Call for participation
+
+Over the coming weeks, we encourage anyone interested to send us proposals for talks, workshops or any other idea you would like to host. GodotCon is an event made by Godot users, so we need you to propose content that will make it a great event for all attendees.
+
+We are interested in any Godot-related topic. It can be a talk about your own Godot project, the tricks you're using in your workflow, a specific feature or plugin that you developed in the engine, etc. We'd like to have diverse speakers and topics, so if you're using Godot for non-gaming topics (education, research, non-game apps, etc.), you're also very welcome to share this with the community. Basically, feel free to propose anything that you think could be worth sharing with fellow Godot users and/or contributors.
+
+As an indication, we propose a duration of 20 minutes (+ 5-10 min Q&A) for talks, though you can tell us if you'd prefer a different format. A 5 min presentation of your game would be welcome, and a 40 min talk is fine too if the topic is worth it :)
+
+Please send your proposals to godotcon *at* godotengine *·* org with the following information:
+
+* Type (talk, tutorial, live demo… anything you think would be fun to see)
+* Title
+* Abstract (short description of what it will be about)
+* Preferred communication method (for us to contact you)
+
+Don't overthink the above too much, we'd prefer to know ASAP who may give a talk, and we can fill in more details later on.
+
+For inspiration, feel free to review the schedules of past events for a glimpse at the kind of activities that we usually have ([Brussels 2019](/article/schedule-godotcon-2019-brussels), [Poznań 2019](/article/schedule-godotcon-2019-poznan), [Brussels 2020](/article/schedule-godotcon-2020-brussels)).
+
+We will schedule the event as soon as possible and get back to you if we accept your presentation so you can start working on it. Please, try to send your proposals **before the 31st of December** so there is plenty of time to schedule and prepare it.
+
+# More questions?
+
+For any other questions, please, don't hesitate to write to that same mail (godotcon *at* godotengine *·* org) and the GodotCon team (Aina, Ilaria, Julian, and Wojciech) will try to solve your doubts.
+
+Thanks everyone and we hope to see you at our first Online GodotCon 2021!
\ No newline at end of file
diff --git a/collections/_article/call-participation-godotcon-2019.md b/collections/_article/call-participation-godotcon-2019.md
new file mode 100644
index 0000000000..5a72b9ccae
--- /dev/null
+++ b/collections/_article/call-participation-godotcon-2019.md
@@ -0,0 +1,40 @@
+---
+title: "Call for participation for GodotCon 2019"
+excerpt: "We have a full week of Godot-related events upcoming in Brussels, Belgium, with the Godot Sprint (31 Jan & 1 Feb 2019), FOSDEM (2-3 Feb 2019) and GodotCon (4-5 Feb 2019)! The venue for the Sprint and GodotCon has now been found, it will be the Ludus Académie in Brussels. We're now asking for proposals of talks, workshops, etc. from GodotCon attendees. The speakers lineup will be announced on this blog in January."
+categories: ["events"]
+author: Rémi Verschelde
+image: /storage/app/uploads/public/5c1/8f7/f3c/5c18f7f3cc9b6563814474.png
+date: 2018-12-18 13:34:46
+---
+
+Last month [we announced the **GodotCon 2019**](/article/meet-community-fosdem-and-godotcon-2019) in Brussels (4-5 Feb 2019), as well as a contributors-focused **Godot Sprint** (31 Jan & 1 Feb 2019) and our stand at the [**FOSDEM 2019**](https://fosdem.org) (2-3 Feb 2019).
+
+We have a few updates since then:
+
+- We found a venue for GodotCon and the Godot Sprint: it will be at the [**Ludus Académie**](http://www.ludus-academie.com), like last year (Quai du Commerce, 48, 1000 Brussels). Thanks a ton to the Ludus staff and students for generously hosting us another year :)
+- Our stand at FOSDEM was confirmed! We're still waiting on an answer to Juan's talk proposal.
+- *Update:* Juan's main track at FOSDEM was just confirmed! Stay tuned for details.
+
+If you haven't done so yet, we encourage you to book accommodation in the vicinity of the Ludus Académie ([OpenStreetMap](https://www.openstreetmap.org/?mlat=50.85717&mlon=4.34818#map=19/50.85717/4.34818)). Note that Brussels public transportation network works quite well, so it's fine if you're staying a bit further away.
+
+[**You can still register!**](https://framaforms.org/registration-for-godotcon-godot-sprint-brussels-2019-1541594499)+ + + +### ARCore + +Not to leave out Android developers for AR support, ARCore is nearly working as well. There are a few more things to resolve before it is on par with the ARKit 1.0 implementation and in a mergeable state. We're putting the final touches on the export functionality and on plane detection. Everything else is working. + + +### Valve Index + +HTC Vive support through OpenVR was one of the first platforms Godot supported and it will come as no surprise that the Valve Index works fine with the current drivers. + +What is missing is support for the new Index controllers, formally known as knuckles controllers. These controllers have full finger tracking support and this will require enhancements to both the Godot core and the OpenVR driver to fully support this new feature. For now they only support the standard controller functions. + +Valve has reached out to the Godot team and offered help so this will likely be our next big addition. + +### How to get my hands on this + +Just to re-iterate, ARKit and GearVR/Oculus Go/Oculus Quest support will be available in Godot 3.2. If you want to play around with any of this already you will need to compile Godot from source. \ No newline at end of file diff --git a/collections/_article/godot-3-2-docs-sprint.md b/collections/_article/godot-3-2-docs-sprint.md new file mode 100644 index 0000000000..610268b7c9 --- /dev/null +++ b/collections/_article/godot-3-2-docs-sprint.md @@ -0,0 +1,52 @@ +--- +title: "Let's complete the docs: Godot 3.2 Docs Sprint" +excerpt: "We're starting a series of docs sprints once again to make Godot's reference and documentation as good as they can be! Together, we can improve everyone's experience using the engine." +categories: ["events"] +author: Nathan GDQuest +image: /storage/app/uploads/public/5cf/4b8/f7d/5cf4b8f7daf66826927105.jpg +date: 2019-06-07 17:00:00 +--- + +We're starting a series of docs sprints once again to make Godot's reference and documentation as good as they can be! Together, we can improve everyone's experience using the engine. + +Godot keeps growing at a fast pace. With **over 900 contributors** at the time of writing, new features and improvements come to the engine every week. + +We have to keep up with the documentation so that beginners have the best experience possible learning the program, and so that people keep finding the information they need. + +That's why we are running new documentation sprints! Let's make the docs even better once again! + +Our priorities are to: + +1. **Complete the built-in code reference** +2. **Find outdated explanations** in the reference and in the manual +3. Edit the reference and the manual to make them **clearer and more accessible** + +The code reference is down to **73% complete at the time of writing**. We want to get it as close as possible to 100%. + + + +We can do this together. [Back in 2017](/article/first-godot-3-docs-sprint-sept-9), in the months leading to the release of Godot 3.0 and with the help of dedicated contributors, we took the reference from 30% to 70% complete in just a few weeks! The manual got its great [Getting Started](https://docs.godotengine.org/en/latest/getting_started/step_by_step/index.html) section at that time, with a lot of work from KidsCanCode, among others. + +## Let's get started together ## + +Join me for a 4 hours livestream starting on Sunday, June 9, 11PM UTC. *The video replay is available below.* + + + +## How can I participate? ## + +If you want to contribute to the code reference, starting by reading the [**Contribute to the Class Reference**](https://docs.godotengine.org/en/latest/community/contributing/updating_the_class_reference.html) page to learn about the workflow. + + +I made a complete video tutorial to show you the entire workflow, explain the best practices, and my techniques to be as productive as possible: + + + + +Then, you can get started anytime. If you feel like writing the reference straight, check out the [**Docs writing guidelines**](https://docs.godotengine.org/en/latest/community/contributing/docs_writing_guidelines.html), then make sure to check the [existing documentation-related issues](https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3Adocumentation) to see what other contributors reported. + +Use this shared document to let everyone know what you're working on: https://hackmd.io/@gdquest/godot-docs-sprint + +If you don't feel like you can write, you can also create issues with your feedback about parts of the reference that are not clear, so that other writers can fix them. No need to point out empty classes though as we have a tool to find them in the Godot repository. + +Hop on the #documentation channel [on Discord](https://discordapp.com/invite/zH7NUgz) to get in touch with fellow contributors. \ No newline at end of file diff --git a/collections/_article/godot-3-2-will-get-new-android-plugin-system.md b/collections/_article/godot-3-2-will-get-new-android-plugin-system.md new file mode 100644 index 0000000000..49dc408294 --- /dev/null +++ b/collections/_article/godot-3-2-will-get-new-android-plugin-system.md @@ -0,0 +1,58 @@ +--- +title: "Godot 3.2 will get a new Android plugin system" +excerpt: "Godot has the simplest and most efficient Android deploy system you can find in any game engine. With a single click, your project is runing on the phone. With a single option (network fs deploy) your gigabyte-sized project is running on your device in mere seconds. You can use the editor to debug your running game while it runs on your device and you can make changes in the scenes or scripts and they will reflect in real-time in your phone or tablet. The big drawback, however, was that adding plugins was a pain in the butt." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5cc/0dd/a5a/5cc0dda5a3834246752408.png +date: 2019-04-24 00:00:00 +--- + +Godot has a simple and efficient Android deploy system. With a single click, your project is running on your phone. With a single option (network filesystem deployment) your gigabyte-sized project is running and updating on your device in seconds. You can use the editor to debug your running game while playing on your device and you can make changes in the scenes or scripts and they will reflect in real-time on your phone or tablet. The big drawback until now, however, was that adding plugins was a pain in the butt. + +Beginnig with Godot 3.2, the Android plugins system has been overhauled. It is no longer required to recompile the engine to add a new plugin. + + +### New custom build system + +Godot export templates for Android projects are just two *.apk* files, one for debug and one for release. On export, Godot fills them with the project files and tweaks some internal variables of the format. This works well in general, but many times the Android project needs to be actually modified and the current approach is not flexible enough. + +Instead of going the way of other engines, which just export an Android project, it was decided to keep the current, easy-to-use approach, but to make it easier to generate the base templates from source. + +To do this, there is a very simple option in the *Project* menu to install the *build template*: + + + +When used, the Godot Android project that is used to build Godot for Android is installed in *"res://android/build"*, including full Java source code (a proper *.gdignore* file is added in *"res://android"* to avoid Godot filesystem dock from entering this folder). + +When the build template is installed, the following option can be turned on in the Android export presets: + + + +And from now on, every time the project is exported, *gradle* will be executed to produce fresh export templates from the Android source. The output (as well as potential errors) is displayed in the editor UI: + + + +The generated templates are used automatically without any user intervention. + +Setting this system up still requires installing the Java and Android SDK in order for Godot to build, but detailed instructions can be found [in this new tutorial](https://docs.godotengine.org/en/latest/getting_started/workflow/export/android_custom_build.html). + + +### New plugin system + +Having the Godot Android project source built automatically allows doing modifications to it, in a way more similar to how it works in other engines. This way you can keep modifying your Android project and bypass the rigidity of the export system as desired. + +Still, however, the problem persists where, if a new Godot version is released, the Android build template will need to be erased and updated, discarding any changes you may have done to it. + +To avoid this situation, a new plugin system was also added. This allows adding plugins inside the *"res://android"* directory (with any name other than *"build"*, of course). When Godot exports using the *custom build* option, the plugins are be compiled-in automatically. + +Plugins allow extending the existing base build template by adding extra files and resources to it in outside directories. They also support blitting chunks of text into *AndroidManifest.xml* and *build.gradle*, so these files can be modified without risking to lose these changes as soon as the build template is updated. + +The code part (Java) for creating plugins remains unmodified so existing plugins should be easy to port to the new system. For more details on how to create them, see [this new tutorial](https://docs.godotengine.org/en/latest/tutorials/plugins/android/android_plugin.html). + +As plugins are just extra files that are added to the project, you can now also distribute them via our [asset library](https://godotengine.org/asset-library/asset). This was not possible before. + +### Future + +With upcoming Godot 3.2, it will be very easy for both our community and third party vendors to create and distribute Android add-ons (such as Ad-Mob, Firebase, Facebook, etc) for others to use. Here's towards a flourishing ecosystem! + +And as always, remember that this is done with love from us. This was a highly requested feature that we're glad to finally be able to provide. If you aren't already, please consider [becoming our Patron](https://www.patreon.com/godotengine) and help Godot's main developers work full time on the project, so the world can have a free and open source tool that lets you create games without any restrictions. Even a small donation is a huge help! \ No newline at end of file diff --git a/collections/_article/godot-3-3-has-arrived.md b/collections/_article/godot-3-3-has-arrived.md new file mode 100644 index 0000000000..3446cdf5cc --- /dev/null +++ b/collections/_article/godot-3-3-has-arrived.md @@ -0,0 +1,450 @@ +--- +title: "Godot 3.3 has arrived, with a focus on optimization and reliability" +excerpt: "All Godot contributors are delighted to release our latest milestone today, Godot 3.3, after more than 7 months of development! +This release was initially planned as a 3.2.4 update to the 3.2 branch, but it grew to become a feature-packed update well worth of opening a new stable branch." +categories: ["release"] +author: Rémi Verschelde +image: /storage/app/uploads/public/608/097/1a7/6080971a7203c431406770.png +date: 2021-04-21 22:20:00 +--- + +All Godot contributors are delighted to release our latest milestone today, **Godot 3.3**, after more than 7 months of development! +This release was initially planned as a 3.2.4 update to the 3.2 branch, but it grew to become a feature-packed update well worth of opening a new stable branch. + +While most development focus is on our upcoming Godot 4.0 release, many contributors and users want a robust and mature 3.x branch to develop and publish their games *today*, so it's important for us to keep giving Godot 3 users an improved gamedev experience. As such, most of the focus was on implementing missing features or bugfixes which are critical for publishing 2D and 3D games with Godot 3, and on making the existing features more optimized and reliable. + +**Godot 3.3 is compatible with Godot 3.2.x and is a recommended upgrade for all 3.2.x users.** + + +## [Download](/download) + +[**Download Godot 3.3 now**](/download) and read on to learn more about our versioning update, our plans for support, and of course the many new features in this update. + + + +## Versioning change + +When we released [Godot 3.2](/article/here-comes-godot-3-2) in January 2020, we switched the development focus towards the **upcoming Godot 4.0**, which is a major, compatibility-breaking rewrite of the engine's core and rendering. + +We knew this would take a while, so we decided to make the 3.2 branch a **long-term support** branch, which would receive 3.2.x updates with bug fixes, but also new features as long as they don't require breaking compatibility. This led us to have a quite [feature-packed 3.2.2 release](/article/maintenance-release-godot-3-2-2), and for over 6 months we'd been working on another feature-heavy 3.2.4 milestone. + +Along the way, we realized that our versioning scheme was too confusing and limiting, and that it could benefit from a change. So what was planned to be Godot 3.2.4 has been [**renamed to 3.3**](/article/versioning-change-godot-3x), and this is the release we're publishing today. + +As such, Godot 3.3 is fully compatible with Godot 3.2.x (like you'd expect from a release named 3.2.4) and is a **recommended upgrade** for all users. + +This rename also means that no new release will happen in the 3.2 branch. The [`3.2`](https://github.com/godotengine/godot/tree/3.2) branch on Git has been reset to the `3.2.3-stable` state, since all subsequent work done in that branch is now part of the [`3.3`](https://github.com/godotengine/godot/tree/3.3) branch. + + + +## Long-term support for 3.x + +Since we renamed 3.2.4 to 3.3, thus opening up a new stable branch, how does this impact our plans for long-term support while Godot 4.0 is being worked on? + +We've updated our [**release policy**](https://docs.godotengine.org/en/3.3/about/release_policy.html) to better reflect our intention to follow [Semantic Versioning](https://semver.org/), and the support expectations for each branch. + +Like 3.0 before it, the upcoming Godot 4.0 release will be a significant change in the Godot ecosystem, and we expect that users will keep using Godot 3.x for a while, until Godot 4.x is stable enough and works reliably on all hardware. + +So we've reopened a [**development branch for 3.x releases**](https://github.com/godotengine/godot/tree/3.x), which was used to develop this version 3.3. We'll now use it to develop **Godot 3.4**, which will be another feature release that aims at being compatible with older Godot 3.x versions (and will only contain some compatible changes backported from the in-development 4.0 version). + +We don't have an ETA for 3.4 yet, but we're aiming for shorter release cycles for upcoming 3.x releases, now that we have a fairly mature base to build upon. + +We intend to keep supporting the 3.x branch with minor releases (3.4, 3.5, etc.) as long as we have both users and contributors interested in such updates. There will likely be a time of overlap after Godot 4.0 is released where we still work on 3.x updates in parallel, like we did with Godot 2.1 and 3.x. + +For stable branches (e.g. 3.3.x), we're going back to a stricter application of semantic versioning and those releases will only contain bug fixes and usability/documentation improvements. This should make them risk-free updates for all users. + +All new feature work for Godot 3 will go in the `3.x` branch for the next minor release (e.g. 3.4). This will enable us to publish maintenance updates at a faster pace as soon as we identify a need (critical regressions to fix, security issues, necessary platform updates, etc.). So you can expect Godot 3.3.1 in the coming weeks with a first batch of fixes. + + +## Supporting the project + +Godot is a **not-for-profit organization** dedicated to providing the world with the best possible free and open source game technology. Donations and corporate grants play a vital role in enabling us to develop Godot at this sustained pace, since they are our only source of income, and are used 100% to pay developers to work on the engine. Thanks to all of you patrons from the bottom of our hearts! + +If you use and enjoy Godot, plan to use it, or want support the cause of having a mature, high quality free and open source game engine, then please consider [**becoming our patron**](https://patreon.com/godotengine). If you represent a company and want to let our vast community know that you support our cause, then please consider [becoming our sponsor](https://godotengine.org/donate). Additional funding will enable us to hire more core developers to work full-time on the engine, and thus further improve its development pace and stability. + + + +## Features + +After this long introduction, time to have a look at the many new features included in Godot 3.3! + +There have been thousands of changes, big and small, so listing everything would be impossible. You can however consult the [**detailed changelog**](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#33---2021-04-21), where we attempted to list most relevant changes, separated by category: [additions](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#added), [changes](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#changed), [removals](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#removed), and [fixes](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#fixed). Note that this is a changelog between 3.2.3-stable and 3.3-stable. If you want to know all changes compared to 3.2-stable, you should also consider the intermediate 3.2.x changelogs. + +In the rest of this post, we aim to give a broad overview of the most noteworthy features and changes in Godot 3.3. You can read in order, or use the index below to jump to your areas of interest. + +**Platforms:** + +- Godot editor on the Web! +- Android: App Bundle, subview, signing +- iOS: New plugin API +- HTML5: Threads, GDNative, AudioWorklet +- macOS: ARM64 build, code signing + +**Core:** + +- Threading API modernization +- Dynamic BVH for rendering and GodotPhysics +- Raise errors when accessing deleted objects in debug + +**Rendering:** + +- Unified 2D batching +- New CPU lightmapper +- More rendering improvements + +**Physics:** + +- Many fixes to one-way collisions +- Fixes to KinematicBody collisions +- Cylinder collision shape for GodotPhysics + +**Editor:** + +- Node copy-pasting +- Improved Inspector sub-resource editing +- Import presets configuration +- 3D editor improvements +- Detect external scene changes + +**Other areas:** + +- Improved FBX importer +- WebXR support for VR games +- OpenXR plugin +- MP3 loading and playback +- New `AspectRatioContainer` Control node +- Minimap support in GraphEdit + +Again, this is not an exhaustive list of changes in this release, so we advise interested users to also dive into the [**detailed changelog**](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#33---2021-04-21) to know more. + +--- + + +### Platforms + + +#### Godot editor on the Web! + +Fabio Alessandrelli ([Faless](https://github.com/Faless)) has done a lot of work to enable running the Godot editor on the Web, using the same export code as for Godot-made games (since the Godot editor is developed 100% with the Godot API). These changes have led to countless improvements for Web exports (see below). + +Building upon the [initial prototype](/article/godot-editor-running-web-browser), we've now reached a state where we're happy to release the Web editor in sync with the native version, so you can find the latest stable version on [**editor.godotengine.org**](https://editor.godotengine.org/). + + +*Web editor running the "Ninja Adventure" demo from the eponymous CC0 [asset pack by Pixel-Boy and AAA](https://pixel-boy.itch.io/ninja-adventure-asset-pack).* + +See Fabio's various progress reports to know more about the rationale, use case and implementation details: [first prototype](/article/godot-editor-running-web-browser), [second prototype](/article/godot-web-progress-report-3), [beta version](/article/godot-web-export-progress-report-4), [release candidate](/article/godot-web-progress-report-5), [Progressive Web App](https://godotengine.org/article/godot-web-progress-report-6). + + +#### Android: App Bundle, subview, signing + +[Android App Bundle (AAB)](https://developer.android.com/platform/technology/app-bundle) is a publishing format that enables more efficient distribution of Android apps. Thanks to Aman Jain ([amanj120](https://github.com/amanj120)) and the support of our Android maintainer Fredia Huya-Kouadio ([m4gr3d](https://github.com/m4gr3d)), Godot 3.3 now supports exporting AABs in addition to APKs. + +Google Play recommends publishing AABs since they enable the Play Store to distribute only the preferred native libraries for the ABI of a device, e.g. only armeabi-v7a or arm64-v8a. [In the second half of 2021 AABs will become the only supported publishing format for Google Play.](https://android-developers.googleblog.com/2020/08/recent-android-app-bundle-improvements.html) + + + +Additionally, many other features have been implemented such as [subview embedding](https://github.com/godotengine/godot-proposals/issues/1064), support for [cutout/notches on Android 9+](https://github.com/godotengine/godot/pull/43104), and implementation of [mouse events](https://github.com/godotengine/godot/pull/42360) and [external keyboard input](https://github.com/godotengine/godot/pull/40398). + +To accommodate [Google Play requirements](https://support.google.com/googleplay/android-developer/answer/10467955), we [disable the `requestLegacyExternalStorage` attribute](https://github.com/godotengine/godot/pull/47954) when there are no external storage permissions enabled. Note that if you do need access to external storage, Godot will currently still need to set this attribute as support for [scoped storage hasn't been implemented yet](https://github.com/godotengine/godot/issues/38913). + +Similarly, we've updated the signing logic to use `apksigner` instead of the now deprecated `jarsigner`. This requires you to review your Android SDK setup and editor settings to make sure that Godot can find `apksigner` in a compatible version. See [Exporting for Android](https://docs.godotengine.org/en/3.3/getting_started/workflow/export/exporting_for_android.html) for the updated documentation. + + +#### iOS: New plugin API + +[Godot 3.2.2](/article/maintenance-release-godot-3-2-2#android-plugins) introduced a new API for Android plugins which allow building and distributing them easily to end users. + +For 3.3, [Sergey Minakov](https://github.com/naithar) implemented the [same interface for iOS plugins](https://github.com/godotengine/godot/pull/41340). This made it possible to move iOS plugins such as ARKit, GameCenter, InAppStore, etc. to a separate, first-party [godot-ios-plugins](https://github.com/godotengine/godot-ios-plugins) repository, so they can be improved independently of Godot itself. + +And the same can be done for third-party plugins which can now be distributed as convenient plug-and-play packages. See [iOS plugins](https://docs.godotengine.org/en/3.3/tutorials/platform/ios/index.html) for the relevant documentation on creating and using such plugins. + + +#### HTML5: Threads, GDNative, AudioWorklet + +In parallel to working on the Web editor, Fabio did many improvements to the HTML5 platform port which will benefit all users. + +One notable change is that there is now support for both threads and GDNative in the HTML5 platform port. However, due to platform limitations, those are mutually incompatible. +Additionally, the threads support depends on the `SharedArrayBuffer` API, which is not yet supported in all browsers ([notably Safari on macOS and iOS](https://caniuse.com/sharedarraybuffer)). +As such Godot 3.3 comes with three different export templates, see [Exporting for the Web](https://docs.godotengine.org/en/3.3/getting_started/workflow/export/exporting_for_web.html#export-options) for detailed documentation. + +The "threads" build additionally benefits from support for the [AudioWorklet API](https://github.com/godotengine/godot/pull/43454), which allows better audio output without blocking the main thread. + +Fabio also greatly improved support for [gamepads](/article/godot-web-progress-report-5) and [virtual keyboards](https://godotengine.org/article/godot-web-progress-report-7) in the Web export... and tons of other things which would be impossible to mention exhaustively here. But in short, 3.3 is a *massive* release for the Web export. + + + + +#### macOS: ARM64 build, code signing + +Thanks to Pāvels Nadtočajevs ([bruvzg](https://github.com/bruvzg)), Godot 3.2.3 already had support for *compiling* Godot for Apple M1 Macs (ARM64 architecture), but we hadn't updated our infrastructure to provide such builds at the time. With Godot 3.3, we now provide a *universal* binary which supports both x86_64 and ARM64 Macs. As of 3.3, this is only for the *standard* build, not for the *Mono* ones, as we still need more work to be able to cross-compile Mono for Apple M1. + +Additionally, we now provide editor binaries which are *signed and notarized*, so you should no longer need to jump through hoops to run Godot on a Mac. Thanks to Hein-Pieter van Braam-Stewart ([hpvb](https://github.com/hpvb)) and his company [Prehensile Tales](https://prehensile-tales.com/) who provide the Mac and signing certificate needed for this. Both *standard* and *Mono* builds are notarized. + +The export dialog now has support for [signing](https://github.com/godotengine/godot/pull/33447) your builds when you export your game from a Mac, including the [configuration of entitlements](https://github.com/godotengine/godot/pull/46618) (this is sadly not possible from other OSes as it depends on macOS-specific tools). + + + + + + +### Core + + +#### Modernized multi-threading APIs + +After doing this work for the `master` branch (4.0), Pedro J. Estébanez ([RandomShaper](https://github.com/RandomShaper)) backported his [modernization of multi-threading APIs](https://github.com/godotengine/godot/pull/45618) to the `3.x` branch. This builds upon Godot's recent adoption of C++11 and beyond (now C++17 in the `master` branch, C++14 in `3.x`), which provides us with more reliable cross-platform implementations than the ones we had so far. + +This should help fix some issues which could affect specific platforms, as well as improve overall reliability and performance. It is however a fairly major change so if your projects relied heavily on multi-threading APIs and you encounter any issue with 3.3, please make sure to report it. + + +#### Dynamic BVH for rendering and GodotPhysics + +Our contributor [lawnjelly](https://github.com/lawnjelly) seems to have decided to tackle many much needed optimizations for the 3.x branch, to ease our waiting time for Godot 4.0. One such optimization was the implementation of a [dynamic BVH method for spatial partitioning](https://github.com/godotengine/godot/pull/44901) as an alternative to Godot's existing Octree. This aims at solving many performance issues and bugs of the octree implementation, and benefits the rendering and GodotPhysics backends specifically (Bullet already has its own BVH). + +The new BVH is used by default, but [there are project settings](https://github.com/godotengine/godot/pull/44901#issuecomment-758618531) to change that and go back to the octree method if you notice issues in your project. Make sure to report any problem you encounter on GitHub, so that we can keep improving this for Godot 3.4. + + +#### Raise errors when accessing deleted objects in debug + +Most Godot users are familiar with the infamous situation of attempting to access a reference to an Object after it has been freed. The reference does not evaluate to `null`, yet it can't be safely dereferenced, leading to the risk of crashes in release builds if such dereferencing is not verified with `is_instance_valid()`. There were [several fixes around this in 3.2.2](/article/maintenance-release-godot-3-2-2#dangling-variant), and some follow-ups in 3.2.3 but going one step too far: in debug builds in 3.2.3, such references to freed objects *would* evaluation as `null`, thus leading to tricky situations where a game runs fine in the editor (debug) but would error out or crash once exported in release mode. + +Godot 3.3 solves this by [no longer decaying references to freed objects to `null` in debug builds](https://github.com/godotengine/godot/pull/41866), so you should properly get errors in the editor that let you identify which code is problematic. + + + + +### Rendering + + +#### Unified 2D batching + +After implementing [2D batching in GLES2 in 3.2.2](/article/maintenance-release-godot-3-2-2#gles2-batching) and 3.2.3, [lawnjelly](https://github.com/lawnjelly) has [overhauled the system](https://github.com/godotengine/godot/pull/42119) with a common intermediate layer allowing it to operate in GLES3 as well as GLES2. In addition batching has been expanded to cover many other primitives (polys, lines, ninepatches) as well as the rects featured in earlier versions. + +New vertex formats allow many more custom shaders and cases to take advantage of batching than before, and optional 2D software skinning has been added which should allow using 2D skeletal animation on a far wider range of hardware than was previously available. + +As always, it is possible to revert to the legacy renderer by turning off batching in project settings. + + +#### New CPU lightmapper + +The lightmapper in the previous 3.x releases was quickly put together before the 3.0 release and it had some major issues. It was reusing parts of the code for baking GIProbes, and that made it quick but not great in terms of quality. Back in summer 2019 we already knew Godot 4.0 would feature a completely new GPU-based lightmapper, but it required Vulkan support and 4.0 was still far away, so we tasked Joan Fons ([jfons](https://github.com/jfons)), as part of the [GSoC](https://summerofcode.withgoogle.com) program, to write a new CPU lightmapper for Godot 3.x. After a long hiatus in development and a couple of rewrites here and there, the brand new [CPU lightmapper](https://github.com/godotengine/godot/pull/44628) was finally merged into the 3.3 branch at the begining of this year. + +The biggest difference with the old lightmapper is that the new one features proper path tracing, which results in better looking lightmaps. Also, the new lightmapper brings support for denoising using [Open Image Denoise](https://www.openimagedenoise.org/), which results in better-looking lightmaps in the same bake time range. On top of that, other quality of life improvements have been added or back-ported from 4.0, such as support for baking environment lighting, lightmap texture atlassing, per-object resolution scaling, cubic filtering of lightmaps at runtime, and last but not least, automatic disabling of baked lights, which eases up the pain of mixing baked and non-baked objects and light in the same scene. + + + +Note that the new lightmapper uses the [Embree](https://www.embree.org/) raytracing library which is only compatible with `x86_64` hardware. It is therefore not available on 32-bit Windows and Linux builds, nor on Apple Silicon (you can use Rosetta emulation to use the `x86_64` version for baking lightmaps). + + +#### More rendering improvements + +While there's so much rendering work being done for Godot 4.0, the 3.3 release got its fair share of improvements, thanks to the dedicated of contributors such as lawnjelly, Clay John ([clayjohn](https://github.com/clayjohn)), Joan, Hugo Locurcio ([Calinou](https://github.com/Calinou)), Camille Mohr-Daurat ([pouleyKetchoupp](https://github.com/pouleyKetchoupp)), [NHodgesVFX](https://github.com/NHodgesVFX), and more! + +Some examples are: + +- [A new software skinning for MeshInstance](https://github.com/godotengine/godot/pull/40313) to replace the slow GPU skinning on devices that don't support the fast GPU skinning (especially mobile). +- [Optimized transform propagation for hidden 3D objects](https://github.com/godotengine/godot/pull/45583). While you might expect that a hidden node would not cost much in terms of performance, analysis showed this was not always the case. One aspect of this was transform calculations and housekeeping, which has now been greatly reduced in hidden nodes. +- [Configurable amount of lights per object (and increase default from 8 to 32)](https://github.com/godotengine/godot/pull/43606). +- [Improved PCF13 shadow rendering in GLES2 by using a soft PCF filter](https://github.com/godotengine/godot/pull/46301). +- [Various light culling fixes](https://github.com/godotengine/godot/pull/46694). +- And more! Search "rendering" [in the changelog](https://github.com/godotengine/godot/blob/3.x/CHANGELOG.md#33---2021-04-21). + + + +*Better soft shadows in the low-end GLES2 renderer.* + + + + +### Physics + + +#### Many fixes to one-way collisions + +This has been a long-term undertaking involving multiple PRs from multiple contributors, and a number of additional testers and reviewers, so kudos to them: Marcel Admiraal ([madmiraal](https://github.com/madmiraal)), Camille, [bemyak](https://github.com/bemyak), [Rhathe](https://github.com/Rhathe), and more! + +One-way collisions prior to Godot 3.3 had many issues, some known for years but this code had the tendency to regress whenever a given issue got fixed. To solve this, in addition to some [excellent debugging and bug fixing effort](https://github.com/godotengine/godot/pull/42574), Marcel and Camille designed thorough test cases so that the fixes could be validated in a number of different situations. The end result is a lot more reliable, though there are still a number of known issues which will require more fixes and more test cases to be fully ironed out. + + +#### Fixes to KinematicBody collisions + +Camille, Marcel and Juan did significant work on long-standing issues with the reliability of KinematicBody collisions. One of the main changes merged for 3.3 is a change to [KinematicBody's recovery after being stuck in a collider](https://github.com/godotengine/godot/pull/46148), affecting methods such as `move_and_slide()` or `move_and_collide()`. + +As physics code is fairly sensitive and prone to regressions when trying to fix a given edge case, Camille made extensive physics test projects [for 2D](https://github.com/godotengine/godot-demo-projects/tree/master/2d/physics_tests) and [for 3D](https://github.com/godotengine/godot-demo-projects/tree/master/3d/physics_tests), to help validate changes and prevent further regressions. + + + +Here too, there are still a number of known issues to address, and this will be one of Camille's main focus areas for 4.0 in coming months. Many of the upcoming bug fixes will likely be backported to the `3.x` branch for future releases (e.g. 3.4). + + +#### Cylinder collision shape for GodotPhysics + +[As part of his Godot 4.0 work](/article/camille-mohr-daurat-hired-work-physics), Camille is implementing missing features in the GodotPhysics 3D backend to reach feature parity with Bullet. One of these was the support for [Cylinder collision shapes](https://github.com/godotengine/godot/pull/45854), which has been implemented for Godot 4.0 and backported to 3.3. This is an *experimental* feature as of 3.3, as it hasn't received extensive testing yet and there are some known bugs in edge cases, so you can expect further fixes in Godot 3.4. + + + + +### Editor + + +#### Node copy-pasting + +Being able to easily cut/copy and paste nodes sounds like a basic feature to have, but it is only now that it [could finally be implemented in a reliable way](https://github.com/godotengine/godot/pull/34892), thanks to the hard work of Tomasz Chabora ([KoBeWi](https://github.com/KoBeWi)). Previously, to copy nodes within the scene, they had to be duplicated and dragged under the desired parent. Moving nodes between scenes was only possible by using the clunky "Merge from scene" feature. Being able to copy nodes as easily as you can copy text was probably one of the most-wanted features since the first release of Godot! + +There were multiple attempts at implementing it, but it took time to refine them into someting reliable that could be merged, especially due to the need to take into account the full complexity of the scene tree (instanced scenes, editable children, shared or unique resources and subresources, etc.). In Godot 3.3, the dream has come true: nodes can be cut, copied and pasted, both within the same scene and between scenes. Manipulating the scene tree has never been this convenient. + + + +*Hello again, [`logo.png` stickman!](https://twitter.com/01lifeleft/status/959761839897767936)* + + +#### Improved Inspector sub-resource editing + +[After much discussion](https://github.com/godotengine/godot-proposals/issues/2230), Juan Linietsky ([reduz](https://github.com/reduz)) implemented a change to the Inspector to [better highlight sub-resources visually](https://github.com/godotengine/godot/pull/45907), so that it's easier to know which resource you're editing when there are more than two levels. + +This was implemented for Godot 4.0 but was fairly easy to backport, so here you go! The colors and contrast can be customized in the editor settings. + + + + +#### Import presets configuration + +When you add assets to a Godot project, most of them get imported to engine internal formats on the fly based on options configured in the Import dock. There are some pre-existing presets for all asset types, and you can define which preset should be used for all resources of the same type (e.g. "2D Pixel" preset for textures), but until there was no easy way to configure all presets easily in a unified interface. + +For Godot 4.0, Juan implemented a new tab in the Project Settings dialog to [configure those "Import Defaults"](https://github.com/godotengine/godot/pull/46354), and this was backported to Godot 3.3. + + + +Additionally, a new ["Keep" import mode](https://github.com/godotengine/godot/pull/47268) was added to configure specific files to be left as-is (i.e. not imported) by Godot's import system. This is particularly useful for files which you intend to process yourself from scripts based on their raw contents (e.g. using the `File` API, loading it as text or bytes), such as CSV files used as database (as opposed to Godot's default CSV import preset as translation catalogs). + + + + +#### 3D editor improvements + +Contributors such as Aaron Franke ([aaronfranke](https://github.com/aaronfranke)), Joan and Hugo did a significant amount of work improving the usability of the 3D editor for 4.0, and most of it was backported to the 3.3 branch. +This includes changes such as: + +- [Dynamic infinite 3D grid](https://github.com/godotengine/godot/pull/43206) ([further improved here](https://github.com/godotengine/godot/pull/45594)). +- [A much-improved 3D rotation gizmo](https://github.com/godotengine/godot/pull/43016), with [increased opacity for better visibility](https://github.com/godotengine/godot/pull/44384). +- [A better 3D selection gizmo](https://github.com/godotengine/godot/pull/40106). + + + +*To infinity and beyond!* + + +#### Detect external scene changes + +One of the biggest hurdles when working with Godot projects in a team was that it's very easy to overwrite changes made by another person if they modified a currently opened scene. How often did you pull changes from Git to only see them discarded, because Godot didn't detect that the scene had changed? While with scenes you just had to reload them, modifications to `project.godot` by another team member required you to restart the Godot editor to properly apply changes. This was especially problematic during game jams where multiple people work on the same small project simultaneously. + +Thanks to Tomasz again, with Godot 3.3, any external changes to opened scenes or `project.godot`, be it VCS pull or external text editor modification, are [properly detected by the Godot editor](https://github.com/godotengine/godot/pull/31747) and you get an option to either reload the affected files, discard the changes or do nothing (which in most cases means another prompt when the editor is re-focused). + + + +Do note that due to how built-in resources (resources saved within the scene instead of separate files) work, some of them might sometimes not get reloaded correctly (this especially applies to built-in scripts). It's a known infrequent issue, already fixed in Godot 4.0. + + + + +### Scripting + + +#### GDScript + +No big change for GDScript in this release as all the focus has been on the rewrite and optimization of GDScript for Godot 4.0. +Still, there's been a [number of bugfixes](https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+milestone%3A3.3+label%3Atopic%3Agdscript+is%3Amerged) which should make the experience more stable. + +As for eye candy, Yuri Roubinsky ([Chaosus](https://github.com/Chaosus)) implemented a feature to [preview `Color` constants in the auto-completion drop-down](https://github.com/godotengine/godot/pull/43026): + + + + +#### Mono/C# + +C# users will benefit from a [redesign of the solution build output panel](https://github.com/godotengine/godot/pull/42547) made by Ignacio Roldán Etcheverry ([neikeq](https://github.com/neikeq/)): + + + +There have been further fixes to the solution and build system, allowing users to [target .NETFramework with the Godot.NET.Sdk and .NET 5](https://github.com/godotengine/godot/pull/44135). +Moreover a 3.2.2 regression was fixed for [`System.Collections.Generic.List` marshalling](https://github.com/godotengine/godot/pull/45029), and [Unicode identifiers are now properly supported](https://github.com/godotengine/godot/pull/45310). + +There's also been [extensive](https://github.com/godotengine/godot/pull/44373) [work](https://github.com/godotengine/godot/pull/44374) on Mono compatibility with WebAssembly. + + + + +### Other areas + + +#### Improved FBX importer + +Gordon MacPherson ([RevoluPowered](https://github.com/RevoluPowered)) rewrote the prototypical Assimp-based FBX importer that we had in Godot 3.2 to support a lot of the more advanced features used in professional FBX-based workflows. You can read his [devblog about it](/article/fbx-importer-rewritten-for-godot-3-2-4) for details. + + + +In the current state, the new importer works quite well for FBX assets authored in Autodesk Maya. There are known issues with some other types of FBX models which are currently being addressed, and should be fixed in upcoming 3.x (and possibly 3.3.x) releases. If you have models that fail to import properly, please [file a bug report](https://github.com/godotengine/godot/issues) so that we can investigate and solve it. + + +#### WebXR support for VR games + +VR developers got a nice surprise back in September when David Snopek ([dsnopek](https://github.com/dsnopek)) landed a pull request to implement [WebXR support in Godot's HTML5 port](https://github.com/godotengine/godot/pull/42397). Since it was merged earlier this year, we've seen a number of prototypes being developed with 3.3 RC builds' WebXR support, and we're eager to see what the community will create now that it's available in a stable release! + + +*David's talk about WebXR support at Online GodotCon in January 2021.* + + +#### OpenXR plugin + +As one of his first tasks as a new full-time developer, Bastiaan Olij ([BastiaanOlij](https://github.com/BastiaanOlij)) worked on an OpenXR plugin for Godot 3.3, before focusing on rendering optimization for mobile Vulkan in the 4.0 branch. He built on the pre-existing effort by Christoph Haag ([ChristophHaag](https://github.com/ChristophHaag)), porting the Linux-only plugin to Windows, and implementing a first version of the the OpenXR action system. You can [read more in this devblog](https://godotengine.org/article/godot-openxr-support). + +You can [download the GDNative plugin](https://github.com/GodotVR/godot_openxr/releases) directly from its GitHub repository. + + +#### MP3 loading and playback + +We initially avoided the ubiquitous MP3 audio format for two reasons: it was patent encumbered, and less performant than alternatives like OGG Vorbis. Since the patents expired, and a good minimal open source implementation is available ([minimp3](https://github.com/lieff/minimp3)), we finally decided to [include MP3 support in the engine](https://github.com/godotengine/godot/pull/43007). This was implemented by [DeleteSystem32](https://github.com/DeleteSystem32). + +It is still not recommended for audio streams as OGG Vorbis is typically better, but it enables Godot projects to load pre-existing MP3 assets that they can't convert beforehand: assets streamed from the Internet, or loaded by the users from their system. So supporting the ubiquitous MP3 format with a tiny library ends up being quite useful. + + +#### New `AspectRatioContainer` Control node + +Making dynamic UI with containers while keeping control of aspect ratio has been made very easy thanks to the [new `AspectRatioContainer` Control node](https://github.com/godotengine/godot/pull/43807), implemented by Uģis Brēķis ([UgisBrekis](https://github.com/UgisBrekis)) and finalized by Andrii Doroshenko ([Xrayez](https://github.com/Xrayez)). + +This container resizes its child Control nodes based on two parameters: aspect ratio and stretch mode. + + + +*Uģis' original proposal. The merged implementation is slightly different but the features are the same.* + + +#### Minimap support in GraphEdit + +Users of Visual Script and Visual Shaders, as well as developers relying on graphs in their game projects and editor plugins, will find this little UX improvement in Godot 3.3. At the end of the last year Yuri Sizov ([pycbouh](https://github.com/pycbouh)) added an often requested [minimap to the `GraphEdit` control node](https://github.com/godotengine/godot/pull/43416). Located at the bottom right corner of the graph minimap allows to quickly find your way around even a very complex node structure. + + + + +## And many more changes! + +There's *a lot* more that would be worth showcasing in this blog post, but it's already extremely long and to be honest I'm running out of time :D + +Godot 3.3 is ready to use now and we want you to have it without further ado. + +We would like to take the opportunity to thank all of our amazing contributors for all the other great features merged since 3.2.3, and the hundreds of bugfixes and usability improvements done in this release. Even if not listed here, every contribution makes Godot better, and this release is truly the work of hundreds of individuals working together towards a common goal and passion. + +For more details on other changes in Godot 3.3, please consult our [curated changelog](https://github.com/godotengine/godot/blob/3.3/CHANGELOG.md#33---2021-04-21), as well as the raw changelog from Git ([chronological](https://downloads.tuxfamily.org/godotengine/3.3/Godot_v3.3-stable_changelog_chrono.txt), or sorted [by authors](https://downloads.tuxfamily.org/godotengine/3.3/Godot_v3.3-stable_changelog_authors.txt)). + + +## Reporting issues + +Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there's a lot of surface to cover and you might encounter situations which we aren't aware of yet, or couldn't fix in time for this release. There will be 3.3.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to [report any issue you encounter on GitHub](https://github.com/godotengine/godot/issues), so that we can make sure to fix it for our future releases. + + +## Giving back + +As a community effort, Godot relies on individual contributors to improve. In addition to becoming a [Patron](https://patreon.com/godotengine), please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various [community platforms](https://docs.godotengine.org/en/latest/community/channels.html) by answering questions and providing helpful tips. + +Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive. + +[Now go and have fun with 3.3!](/download) \ No newline at end of file diff --git a/collections/_article/godot-3-4-is-released.md b/collections/_article/godot-3-4-is-released.md new file mode 100644 index 0000000000..d9bcac5035 --- /dev/null +++ b/collections/_article/godot-3-4-is-released.md @@ -0,0 +1,406 @@ +--- +title: "Godot 3.4 is released with major features and UX polish" +excerpt: "Godot 3.4 is finally released with a number of major new features and a focus on backporting UX improvements from the in-development 4.0 release. This new release adds portal occlusion culling, a revamped UI theme editor, glTF scene export, an animation RESET track, large files support, a lot of physics improvements and fixes, and more!" +categories: ["release"] +author: Rémi Verschelde +image: /storage/app/uploads/public/618/6bb/7b3/6186bb7b3cb36127140644.jpg +date: 2021-11-06 17:36:16 +--- + +All Godot contributors are delighted to release our latest milestone today, **Godot 3.4**, after more than 6 months of development! + +While most development focus is on our upcoming Godot 4.0 release, many contributors and users want a robust and mature 3.x branch to develop and publish their games *today*, so it's important for us to keep giving Godot 3 users an improved gamedev experience. As such, most of the focus was on implementing missing features or bugfixes which are critical for publishing 2D and 3D games with Godot 3, and on making the existing features more optimized and reliable. + +**Godot 3.4 is compatible with Godot 3.3.x projects and is a recommended upgrade for all 3.3.x users.** + + +## [Download](/download) + +[**Download Godot 3.4 now**](/download) and read on to learn more about the many new features in this update. + +You can try it live with the [**Web Editor**](https://editor.godotengine.org/releases/3.4.stable/) too! + + +## Supporting the project + +Godot is a **not-for-profit organization** dedicated to providing the world with the best possible free and open source game technology. Donations and corporate grants play a vital role in enabling us to develop Godot at this sustained pace, since they are our only source of income, and are used 100% to pay developers to work on the engine. Thanks to all of you patrons from the bottom of our hearts! + +If you use and enjoy Godot, plan to use it, or want support the cause of having a mature, high quality free and open source game engine, then please consider [**becoming our patron**](https://patreon.com/godotengine). If you represent a company and want to let our vast community know that you support our cause, then please consider [becoming our sponsor](https://godotengine.org/donate). Additional funding will enable us to hire more core developers to work full-time on the engine, and thus further improve its development pace and stability. + + + +## Features + +A video is worth a thousand words, and thanks to GDQuest, we have one that gives a great overview of the main highlights of Godot 3.4: + + + +There have been thousands of changes, big and small, so listing everything would be impossible. You can however consult the [**detailed changelog**](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#34---2021-11-05), where we attempted to list most relevant changes, separated by category: [additions](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#added), [changes](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#changed), [removals](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#removed), and [fixes](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#fixed). Note that this is a changelog between 3.3-stable and 3.4-stable, therefore it also includes some of the fixes already made available in intermediate 3.3.x maintenance releases. + +In the rest of this post, we aim to give a broad overview of the most noteworthy features and changes in Godot 3.4. You can read in order, or use the index below to jump to your areas of interest. + +**Core:** + +- Promote object validity checks to release builds +- Large files support (> 2.0 GiB) +- Frame delta smoothing +- Improved input handling +- Crypto: AES and HMAC contexts + +**Rendering:** + +- Portal occlusion culling +- ACES Fitted tonemapper +- Ring emitter for 3D particles +- Shader language features +- More rendering improvements + +**Platforms:** + +- Android: Scoped storage, Play Asset Delivery, input responsiveness +- HTML5: PWA, Godot/JavaScript interface, AudioWorklet +- macOS: Mono universal build, GDNative Framework, notarization + +**Physics:** + +- KinematicBody improvements in 2D and 3D +- Faster and more reliable convex hull generation +- Revamped collision layer grid in the inspector +- Dynamic BVH for Godot Physics 2D +- Improvements and new features in Godot Physics 3D + +**Assets pipeline:** + +- Export 3D scenes as glTF +- Lossless WebP encoding + +**Editor:** + +- Revamped UI theme editor +- Localized class reference +- General usability improvements + +**Other areas:** + +- Animation "reset" track +- 2D viewport scale factor +- Improvements and fixes to path mode for CSGPolygon + +This is not an exhaustive list of changes in this release, so we advise interested users to also dive into the [**detailed changelog**](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#34---2021-10-05) to know more. + +--- + + +### Core + + +#### Promote object validity checks to release builds + +Most Godot users have run into situations where an `Object` instance gets deleted (e.g. by calling `queue_free()`) but is still accessed somewhere else in a script. Such use-after-free access needs to be guarded with `is_instance_valid(obj)`, but this has been surprisingly difficult to get right due to a number of bugs and inconsistencies between *debug* and *release* builds. + +Pedro J. Estébanez ([RandomShaper](https://github.com/RandomShaper)) has become an expert on this topic and made a number of improvements included in [Godot 3.2.2](/article/maintenance-release-godot-3-2-2#dangling-variant) and [Godot 3.3](/article/godot-3-3-has-arrived#deleted-objects-debug). With this new change, the checks which were already performed in *debug* builds have been [promoted to also run in *release* builds](https://github.com/godotengine/godot/pull/51796), solving a discrepancy which was the source of much trouble for Godot users. This has a theoretical performance cost for release builds, but it was found not to be significant. + + +#### Large files support (> 2.0 GiB) + +The `File` API can now manipulate files larger than 2.0 GiB, including PCK files, which used to be a limiting factor for bigger games. +Everything has been refactored to used unsigned 64-bit integers, which means that Godot now supports loading files of up to 8.4 million TiB... which should be sufficient for the foreseeable future. + +Pedro started this work in [2019](https://github.com/godotengine/godot/pull/27247), and Rémi Verschelde ([Akien](https://github.com/akien-mga)) [updated it](https://github.com/godotengine/godot/pull/47254) for the 3.4 release to match the core contributors' consensus. + + +#### Frame delta smoothing + +Currently, frame deltas are measured by sampling the OS clock, which can be subject to considerable random variations. Even when frames are being consistently displayed precisely at the vsync rate, these input timings can throw off object positions. [lawnjelly](https://github.com/lawnjelly) added an option for [frame delta smoothing](https://github.com/godotengine/godot/pull/48390) that detects when Godot is hitting vsync consistently, and replaces the sampled input time with the fixed vsync delta. This can significantly improve the fluidity of motion and give smoother gameplay. This option is enabled by default, but can be turned off if you experience timing-related issues with your projects. + +Another option was added to [sync frame delta after draw](https://github.com/godotengine/godot/pull/48555), which is disabled by default. It may lead to more consistent deltas and further reduce frame stutters for some games. + +Manuel Moos ([zmanuel](https://github.com/zmanuel)) also implemented a fix for occasional [negative frame deltas](https://github.com/godotengine/godot/pull/35617) due to getting out of sync with the OS clock. + + +#### Improved input handling + +[bruvzg](https://github.com/bruvzg) added support for [physical keys](https://github.com/godotengine/godot/pull/46764) in the keyboard InputEvents. Physical keys are a way to map the position of a key based on a standard US QWERTY keyboard layout, so that the same location can be used even when the player's keyboard layout is different. For example mapping movements keys to WASD using physical keys will automatically remap them to ZQSD on a French AZERTY keyboard (where W and Z, and Q and A, are swapped). This makes it easier to support multiple keyboard layouts. + +To simplify some of the most common constructs in input handling code for character movement, Aaron Franke ([aaronfranke](https://github.com/aaronfranke)) added [two new helper methods](https://github.com/godotengine/godot/pull/50788): `Input.get_axis()` and `Input.get_vector()`. These methods allow simplifying code like this: + +```gdscript +var walk = WALK_FORCE * (Input.get_action_strength("move_right") - Input.get_action_strength("move_left")) + +var velocity = Vector2( + Input.get_action_strength("move_right") - Input.get_action_strength("move_left"), + Input.get_action_strength("move_back") - Input.get_action_strength("move_forward") +).normalized() +``` + +To this: + +```gdscript +var walk = WALK_FORCE * Input.get_axis("move_left", "move_right") + +var velocity = Input.get_vector("move_left", "move_right", "move_forward", "move_back") +``` + +For more information, read the ["Which Input singleton method should I use?"](https://docs.godotengine.org/en/stable/tutorials/inputs/controllers_gamepads_joysticks.html#which-input-singleton-method-should-i-use) section of the controller input article. + + +#### Crypto: AES and HMAC contexts + +Fabio Alessandrelli ([fales](https://github.com/Faless)) backported a number of [cryptographic features](https://github.com/godotengine/godot/pull/48144) for the 3.4 release, adding an `AESContext` to provide a scripting interface to AES-ECB and AES-CBC encryption/decryption methods. Godot can now save and load public keys, sign and verify a hash with a RSA key, and encrypt and decrypt RSA keys. + +Jon Bonazza ([jonbonazza](https://github.com/jonbonazza)) and [tavurth](https://github.com/tavurth) respectively implemented and [backported HMAC support](https://github.com/godotengine/godot/pull/48869) in the crypto API via a new `HMACContext`. This can be used as an authentication method notibly to interact with services such as GameAnalytics. + + +### Rendering + + +#### Portal occlusion culling + +Up till now a significant missing feature in the renderer has been the ability to cull (prevent rendering) objects that are within the camera view, but occluded by another object (for instance a wall). Although raster (pixel based) occlusion culling will not be available until Godot 4, some geometrical occlusion methods are being added to Godot 3. + +Thanks to lawnjelly, Godot 3.4 introduces [portal occlusion culling](https://github.com/godotengine/godot/pull/46130), which is a tried and tested occlusion solution that has been used in many games, but does require some manual setup of the scene. As well as performing occlusion culling it also provides a solution for throttling AI and processing based on proximity to the viewer. + + + +In addition the ability to add simple geometrical occluders to scenes is being rolled out, starting with spherical occluders which are available in 3.4. + + +#### ACES Fitted tonemapper + +Godot 3.4 adds a new [ACES Fitted tonemapper option](https://github.com/godotengine/godot/pull/52477) contributed by Endri Lauson ([Lauson1ex](https://github.com/Lauson1ex)) that allows scenes to look more realistic, such as by correctly handling the contrast of bright objects. You can try it out in the [Third Person Shooter (TPS) demo](https://godotengine.org/asset-library/asset/678) which has been updated to use the ACES Fitted tonemapper. + + + + +#### Ring emitter for 3D particles + +Ilaria Cislaghi ([QbieShay](https://github.com/QbieShay)) implemented a new [ring emitter for 3D particles](https://github.com/godotengine/godot/pull/47801) which can emit particles on a ring or hollow cylinder with configurable radii and height. + + + + +#### Shader language features + +Our shader language maintainer Yuri Roubinsky ([Chaosus](https://github.com/Chaosus)) is busy [doing magic on the development branch](/article/improvements-shaders-visual-shaders-godot-4) for Godot 4.0, but with the help of [lyuma](https://github.com/lyuma) some of the most-requested features could be backported to Godot 3.4. + +This includes support for [structs and fragment-to-light varyings](https://github.com/godotengine/godot/pull/48075), as well as [global const arrays](https://github.com/godotengine/godot/pull/50889). The `TIME` built-in uniform was also made [available in custom functions](https://github.com/godotengine/godot/pull/49509) by default. + + + + +#### More rendering improvements + +While there's so much rendering work being done for Godot 4.0, the 3.4 release got its fair share of improvements and bug fixes, thanks to the dedication of many contributors! + +Some examples are: + +- Octahedral map normal/tangent attribute compression ([GH-46800](https://github.com/godotengine/godot/pull/46800)). +- Added basic support for CPU blendshapes in GLES2 ([GH-48480](https://github.com/godotengine/godot/pull/48480), [GH-51363](https://github.com/godotengine/godot/pull/51363)). +- Fix draw order of transparent materials with multiple directional lights in GLES3 ([GH-47129](https://github.com/godotengine/godot/pull/47129)). +- Fixes depth sorting of meshes with transparent textures ([GH-50721](https://github.com/godotengine/godot/pull/50721)). +- Add new 3D inverse-squared point light attenuation as an option ([GH-52918](https://github.com/godotengine/godot/pull/52918)). +- And more! Search "rendering" [in the changelog](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#34---2021-10-05). + + +### Platforms + + +#### Android: Scoped storage, Play Asset Delivery, input responsiveness + +Fredia Huya-Kouadio ([m4gr3d](https://github.com/m4gr3d)) implemented initial support for the new [Android scoped storage API](https://github.com/godotengine/godot/pull/50359), enabling us to target API level 30 as required by Google Play. This doesn't cover all features yet for external storage access, which are [being worked on for Godot 3.5](https://github.com/godotengine/godot/pull/51815). + +Initial support was also implemented for Android's [Play Asset Delivery](https://github.com/godotengine/godot/pull/52526), which replaces APK's expansion files (OBBs) for Android App Bundle (AAB) binaries. + +Pedro added an option for [agile input processing](/article/agile-input-processing-is-here-for-smoother-gameplay), which can help increase responsiveness for input on lower-end mobile devices, so you can keep games playable even if the framerate isn't at a steady 60 FPS. + + + +#### HTML5: PWA, Godot/JavaScript interface, AudioWorklet + +Our HTML5 platform maintainer Fabio kept doing a lot of work for this platform in the 3.4 development branch, which brings us a number of new features and improvements. + +Godot Web projects can now optionally include support for being [installed as Progressive Web Apps](https://godotengine.org/article/godot-web-progress-report-8). + +A new `JavaScriptObject` was exposed to provide an [interface between Godot and JavaScript](https://godotengine.org/article/godot-web-progress-report-9), enabling you to call JavaScript methods directly from your Godot scripts. This makes it much easier to use JavaScript APIs in your Web projects. + +```gdscript +extends Node + +func _ready(): + # Retrieve the `window.console` object. + var console = JavaScript.get_interface("console") + # Call the `window.console.log()` method. + console.log("test") +``` + +AudioWorklet was implemented for multi-threaded builds in Godot 3.3, solving issues with audio playback. But not all browsers or Web games platforms provide support for the necessary multi-threading APIs yet, so for single-threaded exports, [AudioWorklet was also implemented as a non-threaded option](https://github.com/godotengine/godot/pull/52650). Performance is not the best, but it's better than stuttering audio as users might experience on Chrome due to their deprecation of the previous standard `ScriptProcessorNode` approach. + + +#### macOS: Mono universal build, GDNative Framework, notarization + +Thanks to an update of our Mono version to 6.12.0.158 (Preview), macOS builds can now target Apple Silicon too, so the macOS Mono builds are now also universal builds (both `x86_64` and `arm64` support). + +bruvzg also added support for using [macOS `.frameworks` libraries with GDNative](https://github.com/godotengine/godot/pull/46860), and in-editor integration for the [Apple notarization process](https://github.com/godotengine/godot/pull/49276) (only available when exporting **to** macOS **from** macOS). + + + + +### Physics + +Thanks to the work of multiple dedicated contributors, many improvements and fixes have been done in both 2D and 3D physics. It can't be all detailed here, but here's a list of the ones that have the most impact on usability and performance. + + +#### KinematicBody improvements in 2D and 3D + +While character controllers are being reworked for Godot 4.0 to be more reliable and much easier to use out-of-the-box, some major improvements and fixes have been also added to the 3.4 release: +- Better handling of moving platforms thanks to [fabriceci](https://github.com/fabriceci): [GH-50166](https://github.com/godotengine/godot/pull/50166). +- Improved RayShape stability in Godot Physics 2D/3D: [GH-53453](https://github.com/godotengine/godot/pull/53453). +- Various improvements for floor stability in Godot Physics 2D/3D. + + +#### Faster and more reliable convex hull generation + +Morris Arroad ([mortarroad](https://github.com/mortarroad)) has worked on using a more reliable algorithm from Bullet to generate physics convex hulls from meshes. It's now several times faster in complex cases, and has generally better results: [GH-48533](https://github.com/godotengine/godot/pull/48533). + +On top of that, thanks to the common work of Camille Mohr-Daurat ([pouleyKetchoupp](https://github.com/pouleyKetchoupp)), [jitspoe](https://github.com/jitspoe) and [lawnjelly](https://github.com/lawnjelly) there's now an option to generate a simplified convex hull from complex meshes, in order to make a convex hull that's better for performance, at the cost of losing a bit of accuracy. + +Example original mesh (40K vertices): + + +Simplified convex hull of that mesh (56 vertices): + + + +#### Revamped collision layer grid in the inspector + +The [layer grid widget](https://github.com/godotengine/godot/pull/51040) has been improved to be more readable and support up to 32 collision layers in physics. + + + + +#### Dynamic BVH for Godot Physics 2D + +Based on the most part on the work [lawnjelly](https://github.com/lawnjelly) already did [for 3D](https://godotengine.org/article/godot-3-3-has-arrived#dynamic-bvh), [pouleyKetchoupp](https://github.com/pouleyKetchoupp) has added support for using a dynamic BVH for the broadphase in 2D physics: [GH-48314](https://github.com/godotengine/godot/pull/48314). + +Like the 3D version, it generally has better performance and is more reliable, but it's still possible to switch back to the old HashGrid in project settings if needed. + + +#### Improvements and new features in Godot Physics 3D + +While Godot Physics 3D is being worked on to become the default physics engine in 4.0, new features and improvements are backported to 3.x when possible. + +That includes: +- Support for [HeightMap shapes](https://github.com/godotengine/godot/pull/47349) with the same optimizations as in Bullet thanks to the work of Marc Gilleron ([Zylann](https://github.com/Zylann)). +- Support for [Sync to Physics](https://github.com/godotengine/godot/pull/49446). +- Various fixes for RigidBody and KinematicBody. + + + + +### Assets pipeline + + +#### Export 3D scenes as glTF + +The glTF module authored by Ernest Lee ([fire](https://github.com/fire) for Godot 4.0 was [backported to the 3.x branch](https://github.com/godotengine/godot/pull/49120) by lyuma. The biggest feature this adds is the ability to export scenes as glTF. This means you can build a scene in Godot using your favorite tools such as CSG, and then bring all of the mesh data into other 3D applications such as Blender or other Godot versions. + + +#### Lossless WebP encoding + +WebP is a new image format that can replace both JPEG and PNG. It has both lossy and lossless modes which are much more optimized than JPEG and PNG, it has a faster decompression time and a smaller file size compared to PNG. Godot already used WebP for lossy compression, and Godot 3.4 now [defaults to using it for lossless texture compression](https://github.com/godotengine/godot/pull/47835) instead of PNGs, thanks to work from Morris Arroad ([mortarroad](https://github.com/mortarroad)). The importer time might be slightly increased, but the imported file sizes and loading times are [significantly reduced](https://github.com/godotengine/godot/pull/47835#issuecomment-818573160). + +For existing projects, you may want to delete the `res://.import` folder to force a reimport of all lossless compressed textures using WebP. PNG is still supported, and can be enforced as the default via an option. + + +### Editor + + +#### Revamped UI theme editor + +Godot provides an extensive system for customizing the looks of UI nodes, but until this point the tools for that were lacking ease of use and kept some users away from a really cool feature. To address multiple concerns and suggestions Yuri Sizov ([pycbouh](https://github.com/pycbouh)) worked on overhauling the editor tools for theming and skinning. The new theme editor aims to make it as straightforward as possible to adjust your control nodes. You have improve listing of available properties that can be easily overridden for your project. A control picker allows to visually select the node you want to customize right from the preview panel. You can have custom previews from the scenes that make sense for your project. Styleboxes of the same type can be edited together to save you time adjusting their margins and borders. And theming power users can enjoy a new item management dialog that gives a lot of granularity when doing bulk adjustments to Theme resources. + +Take a look at the new theme editor in action in this GDQuest video: + + + + +#### Localized class reference + +Rémi implemented support for localizing the in-editor class reference back in [March 2020](https://github.com/godotengine/godot/pull/37164) for 4.0, and finally decided to [backport the new feature](https://github.com/godotengine/godot/pull/53511) (and first round of [community-authored translations](https://hosted.weblate.org/projects/godot-engine/godot-class-reference/)) for 3.4. + +Godot 3.4 includes class reference translations for Chinese (Simplified) and Spanish with a high rate of completion. French, Japanese, and German also have translations included, but only for a subset of the API. Everyone is welcome to [participate in the translation effort](https://hosted.weblate.org/projects/godot-engine/godot-class-reference/), so that future releases can include more languages and more translated content. + + + + +#### General usability improvements + +The 3.4 release has a *huge* focus on editor usability. Those are changes which are for the most part independent of the big core, rendering and scripting changes in the 4.0 branch, and can therefore be backported relatively easily. +Here's a short selection of some highlights: + +- [Use QuickOpen to load resources in the inspector](https://github.com/godotengine/godot/pull/37228) +- [Rationalize property reversion](https://github.com/godotengine/godot/pull/51166) +- [Allow to create a node at specific position](https://github.com/godotengine/godot/pull/50242) +- [New export templates manager](https://github.com/godotengine/godot/pull/50531) +- [Make several actions in the Inspector dock more obvious](https://github.com/godotengine/godot/pull/50528) +- [Improve the 3D editor manipulation gizmo](https://github.com/godotengine/godot/pull/50597) +- [Improve the animation bezier editor](https://github.com/godotengine/godot/pull/48572) +- And more! Search "editor" [in the changelog](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#34---2021-10-05). + + +### Other areas + + +#### Animation "reset" track + +One of the most common hurdles when using AnimationPlayer is that editing animations will permanently modify the state of your scene. To avoid this, users had to manually undo changes to all properties modified by the animation. + +Now the resetting process can be automated, with the addition of a [RESET animation feature](https://github.com/godotengine/godot/pull/44558) thanks to Pedro. The RESET animation can be automatically added to AnimationPlayer and whenever a new keyframe is inserted for the first time, its value will also be mirrored in the RESET track as a default value. Upon scene save, affected properties are automatically saved with their default values, so editing animation no longer affects what is saved in your scene. + + + + +#### 2D viewport scale factor + +[Ansraer](https://github.com/Ansraer) added a [2D viewport scale factor](https://github.com/godotengine/godot/pull/52137) in the Project Settings, which can be used to make 2D elements larger or smaller, independently of the current stretch mode. + + +#### Improvements and fixes to path mode for CSGPolygon + +CSGPolygon has gotten a number of fixes and improvements in this release, notably thanks to [jitspoe](https://jitspoe) who [added properties](https://github.com/godotengine/godot/pull/52509) to configure angle simplification, UV distance, and path interval when using the Path mode. + + + +## And many more changes! + +There's *a lot* more that would be worth showcasing in this blog post, but it's already fairly long and we're eager to get it published :D + +Godot 3.4 is ready to use now and we want you to have it without further ado. + +We would like to take the opportunity to thank all of our amazing contributors for all the other great features merged since 3.3, and the hundreds of bugfixes and usability improvements done in this release. Even if not listed here, every contribution makes Godot better, and this release is truly the work of hundreds of individuals working together towards a common goal and passion. + +For more details on other changes in Godot 3.4, please consult our [curated changelog](https://github.com/godotengine/godot/blob/3.4-stable/CHANGELOG.md#34---2021-10-05), as well as the raw changelog from Git ([chronological](https://downloads.tuxfamily.org/godotengine/3.4/Godot_v3.4-stable_changelog_chrono.txt), or sorted [by authors](https://downloads.tuxfamily.org/godotengine/3.4/Godot_v3.4-stable_changelog_authors.txt)). + + +## Reporting issues + +Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there's a lot of surface to cover and you might encounter situations which we aren't aware of yet, or couldn't fix in time for this release. There will be 3.4.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to [report any issue you encounter on GitHub](https://github.com/godotengine/godot/issues), so that we can make sure to fix it for our future releases. + + +## Giving back + +As a community effort, Godot relies on individual contributors to improve. In addition to becoming a [Patron](https://patreon.com/godotengine), please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various [community platforms](https://docs.godotengine.org/en/latest/community/channels.html) by answering questions and providing helpful tips. + +Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive. + +[Now go and have fun with 3.4!](/download) \ No newline at end of file diff --git a/collections/_article/godot-3-5-cant-stop-wont-stop.md b/collections/_article/godot-3-5-cant-stop-wont-stop.md new file mode 100644 index 0000000000..20e8d4e635 --- /dev/null +++ b/collections/_article/godot-3-5-cant-stop-wont-stop.md @@ -0,0 +1,194 @@ +--- +title: "Godot 3.5: Can't stop won't stop" +excerpt: "After 9 months of development, Godot 3.5 is out and it comes fully packed with features and quality of life improvements! This includes a new Navigation system, 3D physics interpolation, Label3D and TextMesh, an Android editor port, asynchronous shader compilation, and more!" +categories: ["release"] +author: Rémi Verschelde +image: /storage/app/uploads/public/62e/d1b/71d/62ed1b71d02e7838559300.jpg +date: 2022-08-05 14:29:12 +--- + +After 9 months of development, Godot 3.5 is out and it comes fully packed with features and quality of life improvements! + +While most development focus is on our upcoming Godot 4.0 release, many contributors and users want a robust and mature 3.x branch to develop and publish their games today, so it's important for us to keep giving Godot 3 users an improved gamedev experience. Most of work was aimed at implementing missing features or fixing bugs which are critical for publishing 2D and 3D games with Godot 3.x, and at making the existing features more optimized and reliable. + +**Godot 3.5 is compatible with Godot 3.4.x projects and is a recommended upgrade for all 3.4.x users.** + +## [Download](/download) + +[**Download Godot 3.5 now**](/download) and read on to learn more about the many new features in this update. + +You can try it live with the [**Web Editor**](https://editor.godotengine.org/releases/3.5.stable/) too! + + +## Supporting the project + +Godot is a **not-for-profit organization** dedicated to providing the world with the best possible free and open source game technology. Donations and corporate grants play a vital role in enabling us to develop Godot at this sustained pace, since they are our only source of income, and are used 100% to pay developers to work on the engine. Thanks to all of you patrons from the bottom of our hearts! + +If you use and enjoy Godot, plan to use it, or want support the cause of having a mature, high quality free and open source game engine, then please consider [**becoming our patron**](https://patreon.com/godotengine). If you represent a company and want to let our vast community know that you support our cause, then please consider [becoming our sponsor](https://godotengine.org/donate). Additional funding will enable us to hire more core developers to work full-time on the engine, and thus further improve its development pace and stability. + + + +## Features + +Many new features have been added in Godot 3.5, both small and large. The following is a list of a few of the larger features that we are excited about in no particular order. For a complete list of all changes you can check out our [**curated changelog**](https://github.com/godotengine/godot/blob/3.5-stable/CHANGELOG.md), as well as the raw changelog from Git ([chronological](https://downloads.tuxfamily.org/godotengine/3.5/Godot_v3.5-stable_changelog_chrono.txt), or sorted [by authors](https://downloads.tuxfamily.org/godotengine/3.5/Godot_v3.5-stable_changelog_authors.txt)). + +The amazing [GDQuest folks](https://www.gdquest.com/) prepared a nice video showcasing some of the main highlights of Godot 3.5, check it out! (Excerpts of this video are also included in this page for illustration.) + + + +### New Navigation Server with obstacle avoidance + +Godot 3.5 comes with a fully overhauled navigation system, and this is the result of the dedication of quite a few contributors! First, Andrea Catania ([AndreaCatania](https://github.com/AndreaCatania)) implemented the new Navigation Server for [Godot 4.0](https://github.com/godotengine/godot/pull/34776) back in 2020, which was then backported to 3.x by Jake Young ([Duroxxigar](https://github.com/Duroxxigar)). Since then, [smix8](https://github.com/smix8) has taken over the custody of this area, fixing a lot of bugs and improving the feature set greatly, with the help of Pawel Lampe ([Scony](https://github.com/Scony)) and [lawnjelly](https://github.com/lawnjelly). + +The new NavigationServer adds support for obstacle avoidance using the RVO2 library, and navigation meshes can now be baked at runtime. The whole API is now a lot more flexible than it used to be. + +The backport was done while attempting to preserve API compatibility within reason, but the underlying behavior will change, mainly to provide *a lot* more features and flexibility. We expect that all users will happily move to the new NavigationServer, but please report issues if you see behavior changes for the worse when upgrading from 3.4. + + + +### Physics interpolation in 3D + +Godot can render at frame rates independent from the fixed physics tick rate. This can lead to problems where the movement of objects (which tends to occur on physics ticks) does not line up with the rendered frames, causing unsightly jitter. + +Thanks to [lawnjelly](https://github.com/lawnjelly)'s expertise, you can now find the new `physics/common/physics_interpolation` option in the project settings. Enable this setting and Godot will automatically interpolate objects, smoothing out rendered frames. + +Move your objects and run your game logic in `_physics_process()` to benefit from the new physics interpolation. This ensures your game will run the same on all machines. [Full details are available in the updated docs.](https://docs.godotengine.org/en/3.5/tutorials/physics/interpolation/index.html) + +Fixed timestep interpolation is 3D only for now, but stay tuned as we plan to add 2D support after initial feedback and bug fixing on the 3D version. + +### Better tweening with SceneTreeTween + +Tomasz Chabora ([KoBeWi](https://github.com/KoBeWi)) completely overhauled the Tween class in Godot 4.0 to make it a lot more powerful and flexible. Haoyu Qiu ([timothyqiu](https://github.com/timothyqiu)) backported the feature to Godot 3.5 as `SceneTreeTween` to keep the pre-existing `Tween` and thus preserve compatibility. After the 3.5 update, there are now two separate Tween implementations and you can keep using the original 3.x one, or adopt the new 4.0 API. + +### Time singleton + +Aaron Franke ([aaronfranke](https://github.com/aaronfranke)) added a new `Time` singleton in 4.0. The `Time` singleton provides a better abstraction of the various ways of reading the current time from the Operating System. In 4.0 the various time-related methods were moved from the `OS` singleton to the `Time` singleton. In 3.5 the methods were not removed from the `OS` singleton so either the `OS` or `Time` singleton methods can be used. We recommend using the `Time` singleton as much as possible so that your code will be forward compatible with 4.0. + +### Label3D and TextMesh + +Godot now provides the long awaited Label3D node out of the box to display text in 3D scenes. For more advanced use cases, you can use TextMesh to generate 3D meshes from font glyphs, so you can add WordArt to your scenes ;) + +Both features were implemented by our text rendering expert Pāvels Nadtočajevs ([bruvzg](https://github.com/bruvzg)) in the `master` branch for Godot 4.0, and backported to 3.5. + + + +### Access nodes by unique names + +Godot 3.5 adds the concept of "scene unique names" for nodes to help with the common task of accessing specific nodes from scripts. Nodes with a scene unique name can be referenced easily within their scene using a new `%` name prefix, like so: `get_node("%MyUniqueNode")`. This is particularly useful for GUI if you need to locate a specific Control node which might move in the scene tree as you refactor things. Scene unique names were added to the `master` branch ([GH-60298](https://github.com/godotengine/godot/pull/60298)) by Juan Linietsky ([reduz](https://github.com/reduz)), and backported to 3.5 by Tomasz Chabora ([KoBeWi](https://github.com/KoBeWi)). + + + +### New flow containers + +The two new flow containers (`HFlowContainer` and `VFlowContainer`) arrange child Control nodes vertically or horizontally in a left-to-right or top-to-bottom flow. A line is filled with Control nodes until no more fit on the same line, similar to text in an autowrapped label or the CSS Flexbox layout. + +The new container types are especially useful for dynamic content on different window sizes. This feature was originally developed for Godot 4.0 by Hendrik Brucker ([Geometror](https://github.com/Geometror)) and Haoyu Qiu ([timothyqiu](https://github.com/timothyqiu)) backported it to 3.5. + + + +### Asynchronous shader compilation + caching (ubershader) + +A long awaited improvement to reduce shader compilation stuttering on OpenGL is coming to Godot 3.5, courtesy of Pedro J. Estébanez ([RandomShaper](https://github.com/RandomShaper))! + +This new system uses an "ubershader" for each material (a big shader supporting all possible rendering conditions, slow but compiled on startup, and optionally cached for future runs) while the more efficient and condition-specific shader gets compiled asynchronously. + +This means that the first time a material is used under certain conditions such as types of lights, shadowing enabled or not, etc., rendering may be slower for a second or two, but the slowdown will not be nearly as bad as the typical hiccup caused by classic synchronous compilation. On the most powerful devices it may not even be noticeable. Please test this thoroughly and let us know how it performs on your projects. + +This feature is disabled by default, and can be enabled in the Project Settings in the `rendering/gles3` section (it's a GLES3-only feature). +Keep in mind that this feature is not a silver bullet and its effectiveness depends on whether the underlying hardware supports async shader compilation and how fast it can compile asynchronously. + +### OccluderShapePolygon (3D) + +Following on from the addition of [OccluderShapeSphere in 3.4](/article/godot-3-4-is-released#portal-occlusion-culling), [lawnjelly](https://github.com/lawnjelly) now brings us a more adaptable and easy way to add basic occlusion culling in the form of the OccluderShapePolygon. Add an Occluder node to your scene, and choose to create an OccluderShapePolygon. This should show up initially as a quad. + +You can move the polygon with the node transform, drag the corners to reshape it, add delete points. Anything behind the polygon will be culled from view. + +It is really as simple as that to get started, place them wherever you like in your game level. [Read the updated docs for details](https://docs.godotengine.org/en/3.5/tutorials/3d/occluders.html#occludershapepolygon). + + + +### Android editor port and optimizations + +Two years ago (!), [thebestnom](https://github.com/thebestnom) started working on an Android port of the Godot editor ([GH-36776](https://github.com/godotengine/godot/pull/36776)). Since the Godot editor is built with Godot itself, it wasn't too difficult to imagine compiling the editor for Android with some buildsystem changes. A lot of work was needed to actually make this compiled version work decently on an Android device with improved mouse and keyboard support, better touch input, as well as being able to run the project on top of the editor like on desktop. + +With a lot of testing from interested users, things progressed slowly but steadily and our Android maintainer Fredia Huya-Kouadio ([m4gr3d](https://github.com/m4gr3d)) put the finishing touches to get this work merged for Godot 3.5 ([GH-57747](https://github.com/godotengine/godot/pull/57747/)). The current version doesn't have a lot of mobile specific changes, so it's only really usable on a tablet with keyboard and mouse - but the foundation is there to improve upon, and we're interested in your feedback and ideas on how to make the Godot experience more mobile friendly! + +From now on you'll find APK builds of the Android editor [on our Download page](/download#android)! +Note that builds are currently not signed, so you will get a warning on install. + +This first release is **experimental**. There are a number of known issues with the port currently, and it isn't optimized for use with touch input or virtual keyboards (as such it's recommended to try it with a mouse and physical keyboard). We plan to refine the experience further for Godot 3.6 to make it more usable. + +With [helpful input](https://github.com/godotengine/godot/pull/55604#issuecomment-1077590602) from contributors Dan Edwards ([Gromph](https://github.com/Gromph)) and Péter Magyar ([Relintai](https://github.com/Relintai)), Fredia was also able to fix the low processor usage mode on Android ([GH-59606](https://github.com/godotengine/godot/pull/59606)), which the editor port uses. It should now work fine for users who make non-game applications or non real-time games on Android and want to preserve battery life. + +### Material Overlay + +[fbcosentino](https://github.com/fbcosentino) has worked hard to add the new `material_overlay` property to `MeshInstance`s in both 3.5 and 4.0 simultaneously. The `material_overlay` property allows you to assign a material that will be used to render all surfaces of the mesh again with that material. It functions the same as the `next_pass` material in a `SpatialMaterial`, but it applies to all surfaces of a mesh instead of only the surface to which the `SpatialMaterial` is applied. + +To illustrate, here is the same material applied to our dear enemy with the three different locations: + + + +- Using `next_pass` to apply an effect only applies to one surface at a time. +- Using `material_override` replaces the base material with the new one. +- Using `material_overlay` correctly adds the effect over top of the base material for all surfaces. + +Early adopters of 3.5 and 4.0 have found that this is a very helpful tool and we hope you think so as well! + +### Other rendering changes + +As usual, many new features and bug fixes have been added to the renderer, many of which are backports of features originally planned for 4.0. Among them are: +- [Line drawing in 2D has been optimized](https://github.com/godotengine/godot/pull/54377) for use with the batching renderer and is now several times faster in many cases. +- [Post-processing effects can now be used with transparent Viewports](https://github.com/godotengine/godot/pull/54585) including FXAA, Glow, and DoF. +- Performance of Shadow filtering mode PCF13 has been [drastically improved](https://github.com/godotengine/godot/pull/54160) making it only slightly slower than PCF5 but with much higher quality. +- [Directional Shadow atlas size can now be adjusted at run time](https://github.com/godotengine/godot/pull/54165) instead of requiring a restart to change. This makes it substantially easier to expose as a setting in-game, or to adjust dynamically to reach performance goals. +- [CanvasLayers now make use of the `visibility` property](https://github.com/godotengine/godot/pull/57900) and can be hidden/shown just like CanvasItems. +- As always, [many improvements](https://github.com/godotengine/godot/pull/56794) and fixes to shader editing have been backported from 4.0 to make the experience more approachable and streamlined. + +### Big improvements to VCS UI ([GH-53900](https://github.com/godotengine/godot/pull/53900)) + +Aged like fine wine, Meru Patel ([Janglee123](https://github.com/Janglee123))'s work from [Google Summer of Code 2020](https://godotengine.org/article/gsoc-2020-progress-report-1#vcs-improvements) has been continued and updated by [GSoC 2019 alumnus](https://godotengine.org/article/gsoc-2019-progress-report-3#vcsch-integration) Twarit Waikar ([ChronicallySerious](https://github.com/ChronicallySerious))! + +What is it? A lot of new features for Version Control Systems (VCS) integration in the Godot editor, such as push, pull, and fetch operations, as well as a very nice diff view UI. All these features have been implemented in the official [Git integration plugin](https://github.com/godotengine/godot-git-plugin). Check out the [Releases page](https://github.com/godotengine/godot-git-plugin/releases) for the latest 2.x plugin release supporting Godot 3.5. + +### Hundreds of other improvements + +A ton of other improvements are also included in Godot 3.5 such as a 2D gradient texture you can use for lights, particle placeholders, and masking. The ability to align icons on buttons, the use of property pinning on inherited scenes, theme type variations that allow you to use your global project theme and make variations of anything. We advise interested users to also dive into the [**detailed changelog**](https://github.com/godotengine/godot/blob/3.5-stable/CHANGELOG.md) to know more. + +## Known issues + +We currently have 2 outstanding regressions found in 3.5 RC builds which couldn't be fixed in time for this release: + +- Flicker on some materials when Shader Compilation Mode = Asynchronous + Cache ([GH-63346](https://github.com/godotengine/godot/issues/63346)). +- Bullet KinematicBody (3D) `move_and_collide` fails to return KinematicCollision with small velocity ([GH-62153](https://github.com/godotengine/godot/issues/62153)). + +There is also a slight compatibility breakage with text-based shaders. Visual shaders are not affected unless they use expression nodes: + +- Shaders can no longer use the `1f`/`0f` float literal syntax as it's not valid GLSL ([GH-59316](https://github.com/godotengine/godot/issues/59316)). This change was intentional and will be kept in 4.0 for GLSL compliance. + +We'll update this list with any further regression that the first users of 3.5-stable may report. + +## Reporting issues + +Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there's a lot of surface to cover and you might encounter situations which we aren't aware of yet, or couldn't fix in time for this release. There will be 3.5.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to [report any issue you encounter on GitHub](https://github.com/godotengine/godot/issues), so that we can make sure to fix it for our future releases. + +## Future + +This is not the end of the 3.x branch. A new 3.6 milestone already exists so you can expect some more backports coming from Godot 4.0, and continuous support for your 3.5 projects. + +As Godot 4.0 is [getting close to beta](/article/godot-4-0-development-enters-feature-freeze), most contributors are now focusing on that branch, and rightly so. So expect less feature work and backports for the 3.x branch in the future. The planned 3.6 milestone will mostly serve to wrap up current developments and prepare a **Long Term Support** 3.x branch that will live in parallel to 4.x stable releases, and mostly receive bugfixes. + +## Giving back + +As a community effort, Godot relies on individual contributors to improve. In addition to becoming a [Patron](https://patreon.com/godotengine), please consider giving back by: writing high-quality bug reports, contributing to the code base, writing documentation, writing tutorials (for the docs or on your own space), and supporting others on the various [community platforms](https://docs.godotengine.org/en/latest/community/channels.html) by answering questions and providing helpful tips. + +Last but not least, making games with Godot and crediting the engine goes a long way to help raise its popularity, and thus the number of active contributors who make it better on a daily basis. Remember, we are all in this together and Godot requires community support in every area in order to thrive. + +[Now go and have fun with 3.5!](/download) \ No newline at end of file diff --git a/collections/_article/godot-3-capitole-du-libre-2017.md b/collections/_article/godot-3-capitole-du-libre-2017.md new file mode 100644 index 0000000000..b238cafec1 --- /dev/null +++ b/collections/_article/godot-3-capitole-du-libre-2017.md @@ -0,0 +1,25 @@ +--- +title: "Godot 3 at the Capitole du Libre 2017" +excerpt: "We will be at the Capitole du Libre this week-end with Julian Murgia and Gilles Roudière. It's one of the largest French events dedicated to Free Software, and it's taking place in Toulouse. Come meet us if you're in the area!" +categories: ["events"] +author: Nathan GDQuest +image: /storage/app/uploads/public/5a0/c9d/faa/5a0c9dfaabeed972339224.jpg +date: 2017-11-15 12:00:00 +--- + +We will be at the [Capitole du Libre](https://2017.capitoledulibre.org/) this week-end with [Julian Murgia](https://github.com/StraToN) and [Gilles Roudière](https://github.com/groud). It's one of the largest French events dedicated to Free Software, and it's taking place in Toulouse. + +We will have a stand during the two days where you can chat with us about Godot, play games and buy gorgeous Godot T-Shirts. We will host a Godot 3 **game creation workshop** on Sunday 19/11 starting at 10:30, based on [KidsCanCode's intro to Godot tutorial](http://docs.godotengine.org/en/latest/learning/step_by_step/your_first_game.html). + +## Godot 3 presentation + +I'm also giving a **conference dedicated to Godot 3**, on Saturday 18/11, from 15:00 to 16:00. + +The presentation itself is made in Godot. It's going to be open source and available to the entire community. This way if you want to give a talk anywhere in the world, you don't have to start from scratch. Although it's in French, it's designed to be easy to translate. + + + +The event is **completely free to attend**. There will be a lot of developers, artists and FOSS game creation enthusiasts. If you want to meet, feel free to ping us on social media. + +We hope to see you there! +In the meantime, have a pleasant day. \ No newline at end of file diff --git a/collections/_article/godot-3-capitole-du-libre.md b/collections/_article/godot-3-capitole-du-libre.md new file mode 100644 index 0000000000..0bccb33859 --- /dev/null +++ b/collections/_article/godot-3-capitole-du-libre.md @@ -0,0 +1,67 @@ +--- +title: "Godot 3 at the Capitole du libre" +excerpt: "We met with Julian and Gilles at the Capitole du Libre 2017 in Toulouse. It's one of the largest French events dedicated to Free Software. +We went there to showcase Godot 3 and try to introduce new users to it. Here's our report, with a bonus presentation." +categories: ["events"] +author: Nathan GDQuest +image: /storage/app/uploads/public/5a2/678/7be/5a26787bebf13417068091.jpg +date: 2017-12-05 12:00:00 +--- + +We gathered with [Julian](https://github.com/StraToN) and [Gilles](https://github.com/groud) at the [Capitole du Libre 2017](https://2017.capitoledulibre.org/) in Toulouse. It's one of the largest French events dedicated to Free Software. We went there to showcase Godot 3 and try to introduce new users to it. Here's our event report. + +Passing the word to Gilles Roudière himself. + +## Gilles' perspective + +Julian (*StraToN*) and I (Gilles a.k.a. *Groud*) spent most of our time at the Godot stand. We used Fracteed's demo to showcase the engine, along with Zylann's Wallrider. + +We met a lot of friendly people interested in Godot. Enthusiasts, hobbyists, and even some Unity users looking for an alterative to their game engine! + +More importantly, we met people who are deeply involved into the game developpment community. Especially those from the Toulouse Game Dev association, which regroups both hobbyists and professional game developers in Toulouse. They even asked us to organize a presentation of the engine. Besides, we managed to sell some shirts, bringing 152€ to the project. + +#GodotEngine on the #OculusQuest. Only needed small fixes. Main work by @mux213 @m4gr3d and @godotengine https://t.co/vrk3Pb1YQ2 pic.twitter.com/AF6ztQvi1d
— Christoph (@keksdev) June 25, 2019
+
+
+– Alyosha Stalin, Chief Business Development Officer, Kefir
+ +Like all grants, sponsoring and [donations](/donate) given to the not-for-profit Godot project, these funds are managed by our legal and fiscal sponsor [Software Freedom Conservancy](https://sfconservancy.org), and will be used to accelerate development of our free and open source game engine. + +Such funding enables us to hire more contributors to work on the areas which need it most, as well as renew contracts for the currently hired contractors – always with the guarantee that all the work done by contractors is under Godot's MIT license and beneficial to the community as a whole. + +We’re thankful to all users and companies in the Godot community who take part in making this open source game engine, be it with code, documentation, user support, bug reports, or funding. \ No newline at end of file diff --git a/collections/_article/godot-engine-receiving-new-grant-meta-reality-labs.md b/collections/_article/godot-engine-receiving-new-grant-meta-reality-labs.md new file mode 100644 index 0000000000..c28787927b --- /dev/null +++ b/collections/_article/godot-engine-receiving-new-grant-meta-reality-labs.md @@ -0,0 +1,56 @@ +--- +title: "Godot Engine receiving a new grant from Meta's Reality Labs" +excerpt: "We are delighted to announce that the Godot Engine project is receiving a new grant from Meta's Reality Labs to support our work on the XR capabilities of the engine." +categories: ["news"] +author: Rémi Verschelde +image: /storage/app/uploads/public/61c/334/684/61c3346840ff8863294393.png +date: 2021-12-22 16:00:35 +--- + +We are delighted to announce that the Godot Engine project is receiving a new grant from [Meta's Reality Labs](https://about.facebook.com/realitylabs/) to support our work on the XR capabilities of the engine. + +This renews Reality Labs' engagement to support the free and open source Godot game engine, [after a first grant in December 2020](/article/godot-engine-receiving-support-funded-facebook-reality-labs). This grant will enable us to continue our efforts in providing a high quality, free and open source all-in-one solution for AR and VR applications. + +We designed an XR work package for 2022 which is funded thanks to this generous grant. Like all Godot [donations and corporate sponsoring](https://godotengine.org/donate), this grant is administered by our legal and fiscal sponsor [Software Freedom Conservancy](https://sfconservancy.org/), a not-for-profit charity that promotes software freedom. + +## Looking back at 2021 + +The previous grant allowed Bastiaan Olij to dedicate his time working on XR support in Godot. + +During the year he worked on a new mobile version of the Vulkan renderer, added stereoscopic rendering support through Multiview and rewrote a large part of the core of the XR system in Godot 4 ([devblog](/article/godot-xr-progress-update-june-2021)). + +During the year we also introduced a new implementation of GDNative called GDExtension. As Godot's XR support heavily relies on this plugin architecture, this became a big focus of development ([devblog](/article/introducing-gd-extensions)). + +Most importantly, changing conditions in the XR market led us to bring development of the OpenXR capabilities of Godot forward, adding full OpenGL-based OpenXR support to Godot 3 ([devblog](/article/godot-openxr-support)). + +With the [OpenXR plugin 1.1.0](https://github.com/GodotVR/godot_openxr/releases/tag/1.1.0) release Godot 3 now supports the Meta Quest 1 and 2, Meta Desktop XR (including Link) on Windows, and SteamVR on both Windows and Linux. The upcoming OpenXR plugin 1.1.1 release sees added support for the much anticipated passthrough mode on the Quest alongside various fixes and quality of life improvements. + +A [recent informal poll](https://twitter.com/reduzio/status/1450967662620778501) done by lead developer Juan Linietsky showed that over 5% of those responding are already working on XR projects with Godot. According to this poll over a third of the Godot community is either planning to use, or are already using Godot for XR projects. + +In recent weeks we've seen an uptick in new faces joining the #xr channel on [Godot's Discord](https://discord.gg/4JBkykG) as people are discovering Godot's XR capabilities. + +## Looking forward to 2022 + +The new grant from Meta's Reality Labs allows us to keep our commitment going forward to making Godot a great choice as an XR platform. + +The work package we put together for the coming year divides the work into two major sections. + +About half of the funds are dedicated to continue the work on XR support itself. This includes: +- Working on several areas identified during the previous year as requiring improvements. +- Working on making the OpenXR functionality support more devices. +- Implementing various new features announced in recent months such as those announced by Meta during their keynotes session. + +We're even more excited to announce what we're planning to do with the other half! +As is well known within the Godot community, the Godot editor in essence is a Godot game in itself. We are planning on building upon this functionality by bringing the Godot editing experience into XR. There are two main objectives here: +1) Working on XR games means constantly switching between desktop and wearing a headset, this will alleviate part of that frustration. +2) The improved spatial awareness that XR offers makes authoring scenes and levels inside of XR an appealing choice, we believe that even level designers who are working on non XR 3D games may find this workflow productive. + +Finally, just like Godot is now able to run the editor in a browser, we are aiming to have this functionality run on stand alone devices such as the Meta Quest. + +All this work will of course be fully free and open source like the rest of Godot Engine, and will be made available in future Godot releases, either built-in or as first-party plugins. + +## Supporting Godot development + +Godot is a fully not-for-profit open source game engine, and all development happens thanks to the dedication of hundreds of contributors, including a handful of paid developers. +These paid developers could be hired thanks to user donations (Patreon) and corporate sponsoring, as well as grants such as the one given by Meta's Reality Labs. +We're thankful to all users and companies in the Godot community who take part in making this game engine, be it with code, documentation, user support, bug reports, or funding. \ No newline at end of file diff --git a/collections/_article/godot-engine-receiving-support-funded-facebook-reality-labs.md b/collections/_article/godot-engine-receiving-support-funded-facebook-reality-labs.md new file mode 100644 index 0000000000..f04bac5d54 --- /dev/null +++ b/collections/_article/godot-engine-receiving-support-funded-facebook-reality-labs.md @@ -0,0 +1,49 @@ +--- +title: "Godot Engine receiving support funded by Facebook Reality Labs" +excerpt: "It is with great excitement that we announce that the Godot Engine project is receiving support funded by a grant from Facebook Reality Labs to further the development of Virtual Reality (VR) features within Godot." +categories: ["news"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5fd/3d8/93c/5fd3d893cc1bb743932204.png +date: 2020-12-11 20:36:52 +--- + +It is with great excitement that we announce that the **[Godot Engine](https://godotengine.org) project is receiving support funded by a grant from [Facebook Reality Labs](https://about.fb.com/realitylabs/)** to further the development of Virtual Reality (VR) features within Godot. + +Godot is a not-for-profit free and open source game engine which aims at empowering all users in their 2D and 3D game development projects. This grant will enable us to accelerate our efforts in providing first-class support for VR technologies. This includes cross-platform OpenXR support, an extended input action system for VR, Vulkan rendering and optimizations on mobile, and more! + +We designed a work package for VR and mobile rendering which we are now able to fund thanks to this generous grant. Like all Godot [donations and corporate sponsoring](https://godotengine.org/donate), this grant is administered by our legal and fiscal sponsor [Software Freedom Conservancy](https://sfconservancy.org/), a not-for-profit charity that promotes software freedom. + +## VR support in Godot + +Godot has had initial VR support since [version 3.0 in 2018](https://godotengine.org/article/godot-3-0-released#vr), thanks to the dedication of our contributor [Bastiaan Olij](https://github.com/BastiaanOlij) who implemented all AR and VR features in the engine. As of Godot 3.2, many VR devices are supported through the official [OpenVR](https://godotengine.org/asset-library/asset/150), [Oculus VR](https://godotengine.org/asset-library/asset/164) and [Oculus Mobile VR](https://godotengine.org/asset-library/asset/500) implementations. A vibrant community of VR developers is now actively working with Godot on VR titles for most platforms. + +## VR work package for 2021 + +Bastiaan and the growing Godot VR community have created a great ecosystem, and this grant will enable us to go further and faster. We will now be able to **hire Bastiaan Olij full-time** starting in February 2021! + +Bastiaan is a senior generalist developer who has been one of our top contributors since 2016, working primarily on AR and VR support, but also on [GDNative](https://docs.godotengine.org/en/latest/tutorials/scripting/gdnative/what_is_gdnative.html), mobile platform ports (Android and iOS) as well as rendering features. Having him available full-time for Godot work will be greatly beneficial to the project and to the contributors he will be able to help on the way. + +Bastiaan’s main tasks in 2021 will be related to VR and rendering: + +- **OpenXR implementation for desktop and mobile.** OpenXR is the new open standard for XR (Extended Reality, encompasses Augmented Reality (AR) and Virtual Reality (VR)). The OpenXR specification reached version 1.0 in 2019, and now has [**multiple conformant implementations by major XR players**](https://www.khronos.org/news/press/multiple-conformant-openxr-implementations-ship-bringing-to-life-the-dream-of-portable-xr-applications) (Oculus, Microsoft, Valve, and more!). As an open source, cross-platform and vendor neutral game engine, we’re thrilled by the support that IHVs are giving to OpenXR and want to rely on it as our main interface. +- **Extending Godot’s input action system to support VR specific actions** across all devices based on their respective capabilities (hand tracking, controller sensors, buttons). +- Adapt the XR plugin system to the new Vulkan renderer design. While Godot 3.2’s XR support is functional, the upcoming Godot 4.0 release changes all the rendering backend and needs work to make XR functional again. +- Implement **Vulkan rendering on Android**. This is necessary for mobile VR devices such as Oculus Quest 2, and will benefit all Godot users who want to make Android games. +- Various rendering optimizations: + + * Stereoscopic rendering enhancements, providing details about the eye for which an image is rendered. + * Support for compositor layers, which make it possible to render e.g. UI as an overlay without going through the eye buffer with lens distortion, allowing for sharper and more stable UI. + * Support for variable rate shading in Vulkan, providing performance gains with techniques such as foveated rendering. + * Rendering optimizations for mobile, implementing alternative techniques to the ones suitable on desktop platforms for better mobile performance. + +As you can see, there’s a lot of work ahead for Bastiaan, and it will benefit both XR and traditional Godot games. + +All this work will of course be fully **free and open source** like the rest of Godot Engine, and will be made available in Godot 4.0, either built-in or as first-party plugins. + +## Supporting Godot development + +Godot is a fully not-for-profit open source game engine, and all development happens thanks to the dedication of hundreds of contributors, including a handful of paid developers. + +These paid developers could be hired thanks to user donations ([Patreon](https://patreon.com/godotengine)) and corporate sponsoring, as well as grants such as the one given by Facebook Reality Labs. + +We’re thankful to all users and companies in the Godot community who take part in making this game engine, be it with code, documentation, user support, bug reports, or funding. \ No newline at end of file diff --git a/collections/_article/godot-engine-was-awarded-epic-megagrant.md b/collections/_article/godot-engine-was-awarded-epic-megagrant.md new file mode 100644 index 0000000000..c889c55c77 --- /dev/null +++ b/collections/_article/godot-engine-was-awarded-epic-megagrant.md @@ -0,0 +1,26 @@ +--- +title: "Godot Engine was awarded an Epic MegaGrant" +excerpt: "With great excitement, today we want to officially announce the great honor of having been awarded an Epic MegaGrant!" +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/5e3/86b/c31/5e386bc31db0b649571269.png +date: 2020-02-03 00:00:00 +--- + +With great excitement, today we want to officially announce the great honor of having been awarded an Epic MegaGrant! + +This is a huge honor for us and greatly helps to keep on improving Godot development at an even greater pace. We want to personally thank Tim Sweeney for the encouragement and support, and for sharing the belief that open source software makes the world a better place. + +## The grant + +Godot applied for a $250k usd grant for the category of open source graphics software, (which does not have the necessary requirement to be related to Unreal Engine), and expressed the wish to use the grant to improve graphics rendering as well as our built-in- game development language, GDScript. + +Both are areas where the Godot contributor community consistently innovates and we believe this effort, together with the very permissive license, can eventually be used to benefit the industry as a whole. + +The grant was awarded at the beginning of this month and we are still discussing the next steps to follow. + +## Future + +We are still discussing how the budget will be used and allocated so expect announcements (and many improved features) soon thanks to it. + +Stay tuned for more news! \ No newline at end of file diff --git a/collections/_article/godot-gamejam-dec-2016-jan-2017.md b/collections/_article/godot-gamejam-dec-2016-jan-2017.md new file mode 100644 index 0000000000..a071367a34 --- /dev/null +++ b/collections/_article/godot-gamejam-dec-2016-jan-2017.md @@ -0,0 +1,40 @@ +--- +title: "Godot Community Game Jam - Dec 2016 / Jan 2017" +excerpt: "After the success of the previous game jams in March and June, we launch a new community game jam for the new year, with the theme \"Two buttons\". Go to https://itch.io/jam/godotjam122016 to partake in the jam, alone or in a team with other community members!" +categories: ["events"] +author: Rémi Verschelde +image: /storage/app/uploads/public/585/28c/770/58528c770b44a828339905.png +date: 2016-12-15 12:30:02 +--- + +After the success of our previous games jams in [March 2016](/article/godot-gamejam-march-2016) and [June 2016](/article/godot-gamejam-june-2016), and since the community seemed pretty motivated for a new one, we are organizing a new Godot Community Game Jam that will run from **16 December 2016 to 31 January 2017**. + +As the previous one, it is an informal jam with relatively loose rules, and not much to gain apart from international fame within the Godot community and more experience with using our great engine! This is why this jam will run for a month and a half, giving everyone plenty of time to experiment with the engine to create something new, beginners and experienced users alike. + +Check the game jam's page on itch.io: https://itch.io/jam/godotjam122016 + +## Jam theme and rules + +The jam will take place from Friday, December 16th 2016 to Tuesday, January 31st 2017, i.e. for one month and a half. [It is hosted on itch.io](https://itch.io/jam/godotjam122016). + +The guys from the [Discord channel](https://discord.gg/qZtf8) took the initiative and gathered some theme proposals, which were then submitted to the vote of the community. The proposal that received the most votes is **Two buttons**, and it will therefore be the main theme of the jam. The other proposals were *Demake*, *No-death*, *Rust / decay* and *Round-based* - those are not part of the voting criteria, but you are free to take them as an additional source of inspiration for your games. + +Contestants are free to interpret the theme as they want, but keep in mind that your interpretation should be understandable if you want voters to give you many points for it. + +Contestants can partake alone or as a team. Reusing existing code and assets is allowed. + +## Open source and educational + +We see this jam as an opportunity for each community member to share their knowledge with other users, which is why we ask that all games developed for this jam are published with their source code and assets under [open source licenses](http://choosealicense.org/), thus helping build quality examples for new Godot users. + +Of course jam participants are free to continue their game after the jam as a proprietary project if they want - only the jam version should be open source for the whole community to learn from it. + +The minimum requirement for a valid jam entry is thus to provide the full source code to play the game; you are of course welcome to also post exported binaries for players that might not be familiar with running Godot projects from source. + +## Have fun! + +The main purpose of this jam is to have fun together as a community of Godot users. If you are beginning with Godot, don't hesitate to ask any question [on our various community channels](/community); there are no silly questions, so go ahead! + +If you are more experienced, why not take this opportunity to try to discover new [features](/features) of Godot that you might not be using yet (e.g. shaders, particles)? You may also use the current development version of Godot 3.0 (no GLES 3 support yet in the master branch though) to do some alpha-testing while working on your jam game. + +Good luck everyone, and enjoy the jam! \ No newline at end of file diff --git a/collections/_article/godot-gamejam-june-2016.md b/collections/_article/godot-gamejam-june-2016.md new file mode 100644 index 0000000000..ae35052484 --- /dev/null +++ b/collections/_article/godot-gamejam-june-2016.md @@ -0,0 +1,40 @@ +--- +title: "Godot Community Game Jam - June 2016" +excerpt: "After the success of the previous game jam in March, we launch a new community game jam for the month of June 2016, with the theme \"Procedural\". Go to https://itch.io/jam/godotjam062016 to partake in the jam, alone or in a team with other community members!" +categories: ["events"] +author: Rémi Verschelde +image: /storage/app/uploads/public/575/1f9/6f2/5751f96f2d777586519643.png +date: 2016-06-03 00:00:00 +--- + +After the success of [our previous game jam](https://itch.io/jam/godotjam032016/results), which had been spontaneously organized by community members, we decided to [start a new game jam](https://itch.io/jam/godotjam062016) for this month of June 2016. + +As the previous one, it is an informal jam with relatively loose rules, and not much to gain apart from international fame within the Godot community and more experience with using our great engine! This is why this jam will run over three weeks, giving everyone plenty of time to expriment with the engine to create something new, beginners and experienced users alike. + +Check the game jam's page on itch.io: https://itch.io/jam/godotjam062016 + +## Jam theme and rules + +The jam will take place from **Saturday, June 4th 0:00 UTC** to **Monday, June 27th 23:59 UTC**, i.e. for a bit more than three weeks (and four week-ends). [It is hosted on itch.io](https://itch.io/jam/godotjam062016). + +After an [intense consultation with the community](/storage/app/uploads/public/575/1f1/78d/5751f178dc70a813162546.jpg), we settled on **Procedural** as the jam's main theme. Contestants are free to interpret it as they want, but keep in mind that your interpretation should be understandable if you want to get points for it. + +We also propose an *optional* bonus theme, **Only two colors**, which can also be interpreted freely. You can decide to use this bonus theme together with the main theme if you want, but it is not mandatory. The contestants that use both themes will have a small bonus, but which shouldn't create a strong disadvantage for contestants that did not use the optional theme. + +Contestants can partake alone or as a team. Reusing existing code and assets is allowed. + +## Open source and educational + +We see this jam as an opportunity for each community member to share their knowledge with other users, which is why we ask that all games developed for this jam are published with their source code and assets under [open source licenses](http://choosealicense.org/), thus helping build quality examples for new Godot users. + +Of course jam participants are free to continue their game after the jam as a proprietary project if they want - only the jam version should be open source for the whole community to learn from it. + +The minimum requirement for a valid jam entry is thus to provide the full source code to play the game; you are of course welcome to also post exported binaries for players that might not be familiar with running Godot projects from source. + +## Have fun! + +The main purpose of this jam is to have fun together as a community of Godot users. If you are beginning with Godot, don't hesitate to ask any question [on our various community channels](/community); there are no silly questions, so go ahead! + +If you are more experienced, why not take this opportunity to try to discover new [features](/features) of Godot that you might not be using yet (e.g. shaders, particles)? You may also use the [current development version of Godot 2.1](https://github.com/godotengine/godot) to do some alpha-testing while working on your jam game. + +Good luck everyone, and enjoy the jam! \ No newline at end of file diff --git a/collections/_article/godot-games-steam-next-fest-oct-2021.md b/collections/_article/godot-games-steam-next-fest-oct-2021.md new file mode 100644 index 0000000000..1f9f0f7192 --- /dev/null +++ b/collections/_article/godot-games-steam-next-fest-oct-2021.md @@ -0,0 +1,298 @@ +--- +title: "Godot games in the Steam Next Fest (October 2021)" +excerpt: "As the days passes and the team and contributors work hard to deliver Godot 4.x and Godot 3.4, we want to shine a light on the amazing projects that are made using Godot." +categories: ["news"] +author: Ilaria Cislaghi +image: /storage/app/uploads/public/615/c8d/d24/615c8dd245136034621315.png +date: 2021-10-05 15:00:00 +--- + +Hello Godotters! + +As the days passes and the team and contributors work hard to deliver Godot 4.x and Godot 3.4, we want to shine a light on the amazing projects that are made using Godot. + +Our project manager Rémi already collected all of them in a [Twitter thread](https://twitter.com/Akien/status/1444052705820004353). The list of games is reproduced below. + +### The Steam Next Fest + +Steam organises a recurring event called the *[Steam Next Fest](https://partner.steamgames.com/doc/marketing/steamnextfest/2021oct)*: + +> Steam Next Fest is a multi-day celebration where fans can try out demos, chat with developers, watch livestreams, and learn about upcoming games on Steam. For developers, Steam Next Fest is an opportunity to get early feedback from players and build an audience for a future launch on Steam. + +**You have until the 7th of October 2021 @ 17:00 UTC to test the games!** + +### Godot games at October's Steam Next Fest + +#### [TailQuest Defense](https://store.steampowered.com/app/824090/TailQuest_Defense/) + +Starting with TailQuest Defense by [Kivano Software](https://twitter.com/KivanoSoftware). +You may recognize the (by now fairly old!) banner picture of the Godot website :) + +[](https://store.steampowered.com/app/824090/TailQuest_Defense/) + +___ + +#### [The Garden Path](https://store.steampowered.com/app/1638500/The_Garden_Path/) + +Enjoy a relaxing time in the nature with The Garden Path by [Louis Durrant](https://twitter.com/LouisDurrant)! + +[](https://store.steampowered.com/app/1638500/The_Garden_Path/) + +___ + +#### [NeJ](https://store.steampowered.com/app/1626620/NeJ/) + +Adventure in a much darker forest this time with [Ben Lega](https://twitter.com/Ben_Lega_Vidya)'s Nej. + +[](https://store.steampowered.com/app/1626620/NeJ/) + +___ + +#### [Lumencraft](https://store.steampowered.com/app/1713810/Lumencraft/) + +Recently revealed but going strongly, here's +[Lumencraft](https://twitter.com/Lumencraft_game) by Godot contributor [@KoBeWi_](https://twitter.com/KoBeWi_) together with [@lrzepecki](https://twitter.com/lrzepecki) [@JohnMeadow3](https://twitter.com/JohnMeadow3) [@PawelMogila](https://twitter.com/PawelMogila) [@DamianWiech](https://twitter.com/DamianWiech). + +[](https://store.steampowered.com/app/1713810/Lumencraft/) + +___ + +#### [Galactic Chef](https://store.steampowered.com/app/1156790/Galactic_Chef/) + +Galactic Chef by [@ThoughtQuake](https://twitter.com/Thoughtquake) lets you become the best cook of the universe (well at least of the Interstellar Culinary Alliance®)! + +[](https://store.steampowered.com/app/1156790/Galactic_Chef/) + +___ + +#### [The Zone: Stalker Stories](https://store.steampowered.com/app/1299540/The_Zone_Stalker_Stories/) + +The Zone: Stalker Stories by [@IlluminatedGms](https://twitter.com/IlluminatedGms) is a story-rich card battler in a post-apocalyptic setting – what's not to love‽ + +[](https://store.steampowered.com/app/1299540/The_Zone_Stalker_Stories/) + +___ + +#### [Martial Law](https://store.steampowered.com/app/1712390/Martial_Law/) + +Martial Law by [@GroupFixer](https://twitter.com/GroupFixer) tells a story about Poland in the communist era, family, and making choices – all with gorgeous pixel art. + +[](https://store.steampowered.com/app/1712390/Martial_Law/) + +___ + +#### [Ex-Zodiac](https://store.steampowered.com/app/1249480/ExZodiac/) + +Ex-Zodiac by [@BenHickling](https://twitter.com/BenHickling) bears a strong similarity to a certain furry on-rails shooter, but we're all longing to scratch this SNES itch so it's very welcome! And it definitely goes beyond that inspiration to be its own very modern arcade shooter. + +[](https://store.steampowered.com/app/1249480/ExZodiac/) + +___ + +#### [Seedlings](https://store.steampowered.com/app/1575510/Seedlings/) + +Bardsley Creative's [@Seedlings_Game](https://twitter.com/Seedlings_Game) is probably the game featuring the most realistic nature graphics you've seen in a while - as they're all derived from photos of the beautiful Aotearoa New Zealand Bird. + +[](https://store.steampowered.com/app/1575510/Seedlings/) + +___ + +#### [RUN: The World In-Between](https://store.steampowered.com/app/1548940/RUN_The_world_inbetween/) + +*Run, boy, run! Running is a victory.* It probably doesn't include Woodkid songs, but [@RunTheVideoGame](https://twitter.com/RunTheVideoGame) +'s soundtrack seems pretty fitting anyway for this fast-paced "die and retry" runner with a beautiful art direction! + +[ +](https://store.steampowered.com/app/1548940/RUN_The_world_inbetween/) + +___ + +#### [Birb Café](https://store.steampowered.com/app/1579300/Birb_Caf/) + +Birb Café by [@birbgames](https://twitter.com/birbgames) has you, a birb, make coffee for furry and feathery customers (who would have guessed)! It's a visual novel with branching paths and multiple endings. We don't know yet if it features skating birbs, we'll see! + +[](https://store.steampowered.com/app/1579300/Birb_Caf/) + +___ + +#### [Woodland Empire](https://store.steampowered.com/app/1419150/Woodland_Empire/) + +Woodland Empire by [@obvlong](https://twitter.com/obvlong) describes itself as an ANTI-citybuilder – control the elements and help your forest grow with thriving fauna and flora. + +[](https://store.steampowered.com/app/1419150/Woodland_Empire/) + +___ + +#### [Smelted Kin: Inhuman Impact](https://store.steampowered.com/app/1604050/Smelted_Kin_Inhuman_Impact/) + +Smelted Kin: Inhuman Impact by [@MicrobatStudio](https://twitter.com/MicrobatStudio) is a 2D shooter in a sci-fi environment, which has you play both a human character and an armored vehicle. + +[](https://store.steampowered.com/app/1604050/Smelted_Kin_Inhuman_Impact/) + +___ + +#### [《文字遊戲》(Word game)](https://store.steampowered.com/app/1109570/_/) + +It's only in Chinese for now, but [@Team9Games](https://twitter.com/Team9Games)'《文字遊戲》 is looking pretty sweet! If we understand correctly, its prequel is "Word Game: Episode 0", which is one of the most popular Godot-made games on Steam (2500 reviews, 99% positive!). + +[](https://store.steampowered.com/app/1109570/_/) + +___ + +#### [Dark Crypt](https://store.steampowered.com/app/1706170/Dark_Crypt/) + +Dark Crypt by [@DaisyGames3](https://twitter.com/DaisyGames3) is a puzzle game with a horror setting, well on topic for the spooky season! + +[](https://store.steampowered.com/app/1706170/Dark_Crypt/) + +___ + +#### [TOCOViX](https://store.steampowered.com/app/1711990/TOCOViX/) + +TOCOViX by [@maxfox21](https://twitter.com/maxfox21) is a colorful strategy game which looks a bit like a board game, playable in singleplayer, local multiplayer or online! + +[](https://store.steampowered.com/app/1711990/TOCOViX/) + +___ + +#### [Tokyo Rogue](https://store.steampowered.com/app/1646090/Tokyo_Rogue/) + +More fast-paced runners you said? Have a go at [@lunaticgames_ca](https://twitter.com/lunaticgames_ca)'s Tokyo Rogue and show your best parkour moves! + +[](https://store.steampowered.com/app/1646090/Tokyo_Rogue/) + +___ + +#### [Spinstar](https://store.steampowered.com/app/1669850/Spinstar/) + +Manipulate gravity in Spinstar, [@PixyDevs](https://twitter.com/PixyDevs)'s precision puzzle platformer with great pixel art and music! + +[](https://store.steampowered.com/app/1669850/Spinstar/) + +___ + +#### [Terra Ventura](https://store.steampowered.com/app/1664580/Terra_Ventura/) + +Terra Ventura by [@LogicalProgres3](https://twitter.com/LogicalProgres3) is a classic isometric action RPG with a ton of content! + +[](https://store.steampowered.com/app/1664580/Terra_Ventura/) + +___ + +#### [The Ballad of Bonky](https://store.steampowered.com/app/1619870/The_Ballad_of_Bonky/) + +Don't miss The Ballad of Bonky by [@knutselco](https://twitter.com/knutselco) and its delightful hand-crafted clay art. This "bouncy arcade adventure" also includes local multiplayer. + +[](https://store.steampowered.com/app/1619870/The_Ballad_of_Bonky/) + +___ + +#### [The Case of the Golden Idol](https://store.steampowered.com/app/1677770/The_Case_of_the_Golden_Idol/) + +Investigate an 18th century murder mystery in The Case of the Golden Idol by [@ColorGray7](https://twitter.com/ColorGray7), with hand-drawn dithered pixel artwork. + +[](https://store.steampowered.com/app/1677770/The_Case_of_the_Golden_Idol/) + +___ + +#### [Longphort](https://store.steampowered.com/app/1683680/Longphort/) + +Let's go further back in time with [@Priory_Games](https://twitter.com/Priory_Games)'s Longphort, a Viking crew management game! Interesting premise? Check it out! + +[](https://store.steampowered.com/app/1683680/Longphort/) + +___ + +#### [Striving for Light](https://store.steampowered.com/app/1646790/Striving_for_Light/) + +Igniting Spark Games' [@StrivingLight](https://twitter.com/StrivingLight) is a rogue-lite ARPG with an "infinite expanding skilltree". + +[](https://store.steampowered.com/app/1646790/Striving_for_Light/) + +___ + +#### [Hashi: Light](https://store.steampowered.com/app/1703650/Hashi_Light/) + +Hashi: Light by amiksemo is a minimalist and casual puzzle game with a ton of puzzles to solve. + +[](https://store.steampowered.com/app/1703650/Hashi_Light/) + +___ + +#### [Long Tail](https://store.steampowered.com/app/1678100/Long_Tail/) + +Long Tail by Kamil Rams is Snake with a twist (a knot?) - adds in route planning based puzzle solving. It's tagged as relaxing so after checking all these cool but content heavy demos, that might be a good one to chill. + +[](https://store.steampowered.com/app/1678100/Long_Tail/) + +___ + +#### [Genetic Fluff](https://store.steampowered.com/app/1403270/Genetic_Fluff/) + +Growing Brains' Genetic Fluff has a lot to unpack, action beat 'em up RPG creature collection adventure game with local split screen multiplayer. + +[](https://store.steampowered.com/app/1403270/Genetic_Fluff/) + +___ + +#### [Ari's Journey](https://store.steampowered.com/app/1721240/Aris_Journey/) + +HackBerry Studio's [@aris_journey](https://twitter.com/aris_journey) is a precision platformer without any platforms. Time your moves well to navigate narrow corridors and collect stars. + +[](https://store.steampowered.com/app/1721240/Aris_Journey/) + +___ + +#### [Cloaks and Capes](https://store.steampowered.com/app/1637950/Cloaks_and_Capes/) + +[CloaksAndCapes](https://twitter.com/CloaksAndCapes) is a side-scroller with a dark theme and rage-inducing bosses! + +[](https://store.steampowered.com/app/1637950/Cloaks_and_Capes/) + +___ + +#### [VoxStory](https://store.steampowered.com/app/1339730/VoxStory__The_Cinematic_TTRPG/) + +[@VoxStoryRPG](https://twitter.com/VoxStoryRPG) by Current Year Gaming brings 3D digital content to tabletop roleplaying. The Game Master creates a 3D voxel world as support for the good old pen and paper roleplaying. + +[](https://store.steampowered.com/app/1339730/VoxStory__The_Cinematic_TTRPG/) + +___ + +#### [Reef Rumble](https://store.steampowered.com/app/1678980/Reef_Rumble/) + +[@ReefRumbleGame](https://twitter.com/ReefRumbleGame) by [@Paul_N_Leduc](https://twitter.com/Paul_N_Leduc) and Maxime Martens is a cartoony fighting/party game for 2 to 8 players, locally or online! + +[](https://store.steampowered.com/app/1678980/Reef_Rumble/) + +___ + +#### [Move Dodge and Kill](https://store.steampowered.com/app/1699500/Move_Dodge_and_Kill/) + +Move Dodge and Kill by [@DjokaGames](https://twitter.com/DjokaGames) is a top-down roguelite shooter in a minimalist neon dungeon. + +[](https://store.steampowered.com/app/1699500/Move_Dodge_and_Kill/) + +___ + +#### [System Under Surveillance](https://store.steampowered.com/app/1655800/System_Under_Surveillance/) + +System Under Surveillance by [@to_pixels](https://twitter.com/to_pixels), a stealth adventure with an adorable robot sidekick! + +[](https://store.steampowered.com/app/1655800/System_Under_Surveillance/) + +___ + +#### [Mechanic 8230](https://store.steampowered.com/app/1432680/Mechanic_8230/) + +[Mechanic 8230](https://twitter.com/Mechanic8230) by Nudiventra is a point and click adventure with a wonderful art direction! + +[](https://store.steampowered.com/app/1432680/Mechanic_8230/) + +___ + +#### [TD Worlds](https://store.steampowered.com/app/1659180/TD_Worlds/) + +And finally, [@TDWorlds_game](https://twitter.com/TDWorlds_game) by MAKSIM VOLKAU is a roguelite strategy game and dynamic storytelling. + +[](https://store.steampowered.com/app/1659180/TD_Worlds/) \ No newline at end of file diff --git a/collections/_article/godot-gdc-2016-aftermath.md b/collections/_article/godot-gdc-2016-aftermath.md new file mode 100644 index 0000000000..2557b7adea --- /dev/null +++ b/collections/_article/godot-gdc-2016-aftermath.md @@ -0,0 +1,42 @@ +--- +title: "Godot at GDC 2016, aftermath" +excerpt: "GDC (or Game Developer's Conference) is an event hosted every year in San Francisco at some point of March. The point of GDC is to reunite as much as possible of the videogame development industry in a single week. The past week, we took Godot to this event!" +categories: ["events"] +author: Juan Linietsky +image: /storage/app/uploads/public/57f/215/1eb/57f2151eb9807140516214.jpg +date: 2016-03-19 00:00:00 +--- + +#### What is that? + +GDC (or Game Developer's Conference) is an event hosted every year in San Francisco at some point in March. The point of GDC is to reunite as much as possible of the video game develoment industry in a single week. The event is used for conferences (educational mostly), business, mixers, award ceremonies (IGF), technology showcases and partying hard with fellow developers. + +It is without a doubt a fantastic time of the year if you are a video game developer and you can attend to it. + +#### Godot at GDC + +We took Godot to GDC with a number of goals, mainly to see the industry feedback to it (see how we can improve) and to find sponsoring for its development by the big companies. + +We spent most of the week meeting with programmers, artists, designers, company representatives, etc. Went to parties, talks and more. + +On the sponsoring side, we have many promising leads but it's probably too early to write about it. + +On the feedback side, what we found, however, was not what we were expecting. The sad truth is that, even after two years of being open source... + +#### No one knows about Godot + +It's as simple as that. Developers and companies are enthusiastic and amazed when we show them Godot, the games that the community is making, the maturity of the engine, etc. Yet, they simply had no idea it existed and never heard about it. + +This GDC, organizers estimated that the number of attendees was over 70.000. One could argue that most of the developers attending GDC are not video game technology enthusiasts so they don't bother looking beyond what the companies ask them to learn (Unity likely). Our problem is not that users dislike Godot, but that developers do not bother to find out if there are alternatives to what they use. + +Amazon, on the other hand, set up an enormous booth for Lumberyard (very fitting to its 40 GB install size :P) and you could see developers surprised there was a new engine around. + +#### We need visibility + +At this point, I think it's becoming quite clear that Godot needs better visibility industry wide, so we should start thinking about ways to achieve that. Some things that come to mind are: + +* We should start contacting company CTOs or technical directors and offer them to do a private showcase of Godot. +* We could actually try to crowdfund a booth at GDC, which would definitely give us visibility in the chunk of the industry that attends the event. A decent booth is quite expensive though (15-25k USD), but we might actually share it with other popular open source software that is used for games such as Blender or Krita. +* It could be interesting to create sets of training materials, so other Godot users could use them to set up jams, workshops, etc. in their local regions too. + +Any ideas are welcome, and this is an issue we'll most definitely be going to be working on during the year. \ No newline at end of file diff --git a/collections/_article/godot-gets-2d-skeletal-deform.md b/collections/_article/godot-gets-2d-skeletal-deform.md new file mode 100644 index 0000000000..153e39d821 --- /dev/null +++ b/collections/_article/godot-gets-2d-skeletal-deform.md @@ -0,0 +1,140 @@ +--- +title: "Godot gets 2D skeletal deform" +excerpt: "Currently, Godot is pretty comfortable for doing 2D cutout animation, with several games in development making use of this feature. + +A very common request, though, was the ability to do custom mesh deformation based on the same bones used to animate separate parts. This would allow deforming such parts, for a more organic animation feel." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5ae/c8f/8c1/5aec8f8c19c0b515935183.gif +date: 2018-05-04 00:00:00 +--- + +Currently, Godot is pretty comfortable for doing [2D cutout animation](http://docs.godotengine.org/en/3.0/tutorials/animation/cutout_animation.html), with several games in development making use of this feature. + +A very common request, though, was the ability to do custom mesh deformation based on the same bones used to animate separate parts. This would allow deforming such parts, for a more organic animation feel. + +This was recently added to GitHub head and, while overall 2D editing is a bit unstable right now (due to a massive reorganization of the 2D editor), it will be soon be possible to fully make use of this feature. + +As always, please remember Godot is made out of love, so please consider [becoming our patron](https://www.patreon.com/godotengine)! + +### How it works + +Two new types of nodes were added: **Skeleton2D** and **Bone2D**. The former is the reference skeleton (much similar to the existing **Skeleton** node for 3D), while the later is actually used to build a bone hierarchy on top of it: + + + +For editing, the workflow is the same as cutout, bones are laid out in a tree then marked as visual bones for editing (they are not visible by default). This is a bit more of a hassle than with dedicated software, but fortunately the process is done only once. + +Of course, compared to dedicated software, this workflow has the huge advantage that nodes are fully accessible within the engine, allowing to mix them up with particles, shaders, other nodes (i.e. swap a sword), and other visual effects built-in to Godot. + + +### Using with MeshInstance2D + +Although the recently added MeshInstance2D node now supports skeletal deforms, it can't be created with such property within the editor. + +This allows, however for the community to write importers for tools such as [Spine](http://esotericsoftware.com/) or [CoaTools](https://github.com/ndee85/coa_tools) that become actual Godot scenes instead of an opaque node. + +### Using with Polygon2D + +The **Polygon2D** node has gained many new features to make working with skeletons easier. Here's a short tutorial on how to use it: + +**Note:** This tutorial is already outdated, endpoints are no longer required and bone editing creates visible bones automatically now, thus making working with skeletons in Godot as easy as in any other software. + + +##### 1-Draw a polygon outline around the image: + +Normally for 2D animation, it's still more convenient to split the object into parts and then use bones on specific parts of them (as they handle overlap better) so actual use of this feature will be more of an extension to the existing cutout workflow. Still, for brevity, this tutorial will show how to do it on a single object. + +Create a *Polygon2D* node, then immediately assign an image to it (otherwise UV editing won't open). + + + +Open the UV editing window (again, without an image assigned, this won't open) + + + +Once open, go to the newly added *Polygon* section of he editor. Once there, click the **+** button to add points. + + + +Draw a close polygon outline around the object: + + +Finally, this will become your actual polygon when editing the scene: + + + + +##### 2-Create a skeleton to match the polygon + +Starting from a **Skeleton2D**, add a hierarchy of **Bone2D** nodes to match the desired skeleton. Remember that each **Bone2D** must be placed where the bone *Starts*. To have a reference where the hierearchy ends, just add a **Position2D** node at the end. + + + +Once you have a chain of bones, you can make them visible in the Bone menu. Just select all bones (except the base, as this acts on a node towards the parent node), and create visual bones: + + + +They will now appear visually and can be manipulated more easily, including setting up IK chains: + + + + +Repeat this process to have a full skeleton. For skeleton points where two bones emerge (as in, the base position for left and right shoulders), having them both in the same position is fine. In fact, in this example, base, left_hip and right_hip share the position and hierarchy level as 3 root bones. + + + +Ok, skeleton is complete! You might have noticed that nodes are showing warnings. This is because they need a *rest* pose. This is the default reference pose for the skeleton, and it must exist before bones are animated (so Godot knows how to rotate or move the points based on how rotated the or moved the bones is). + +Create the rest pose (once the skeleton is complete) by selecting the **Skeleton2D** node and the *Skeleton* menu: + + + + +##### 3-Create splits to improve triangulation + +As polygons are converted to triangles for drawing internally, this process may need some help in order to created less unexpected deformations. Select the **Polygon2D** node and enter the UV menu again. This time go to the *Splits* mode. From there, to the Add Split mode: + + + +Finally, connect sets of two points near bone unions, indicating that you dont want triangles to be generated across such splits: + + + +This process may demand some trial an error, as for complex polygons it may need to be re-adjusted a bit after the process is done. + + +##### 4-Setup polygon for painting + +Exit the UV editor and re-select the **Polygon2D** node. From there go to the *Skeleton* property. Assign the **Skeleton2D** node to it. + + + +Go back to the UV editor and select the *Bones* section, and from there the *Paint* mode: + + + +While the skeleton is visible over the image now, the bones are still not available for painting. + +The **Polygon2D** node needs to store bone painting information. To create this, push the *"Sync Bones to Polygon"* button. If you later add, remove or reparent nodes, you will need to push this button again. This will ensure that the minimum possible paint information is lost each time the skeleton hierarchy is modified. + + + +##### 5-Painting bone weights + +Everything is now ready for weight painting!! Now select bones fromt he list, and paint the area they affect. When a point is fully white, it's fully affected by the bone. When black, it's not affected at all. + +A point may be affected by multiple bones. When this happens, the bone will try to satisfy both bones as best as possible, by averaging their influence. This makes deformation look *soft*. + +Here are some examples on how weights are painted for different bones: + + + + + + +##### 6-Animate!! + +Now have fun animating deformable polygons! + + \ No newline at end of file diff --git a/collections/_article/godot-gets-brand-new-animation-editor-cinematic-support.md b/collections/_article/godot-gets-brand-new-animation-editor-cinematic-support.md new file mode 100644 index 0000000000..87e13d10f2 --- /dev/null +++ b/collections/_article/godot-gets-brand-new-animation-editor-cinematic-support.md @@ -0,0 +1,172 @@ +--- +title: "Godot gets a brand new animation editor (with cinematic support)" +excerpt: "The existing animation system in Godot was already one of the most powerful of any game engine, but its age was starting to show (it was written 10 years ago and barely improved). The new one builds upon the strengths of the previous one but does massive improvements to features and usability." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5b1/96c/a95/5b196ca9551b7541693881.png +date: 2018-06-07 12:00:00 +--- + +The existing animation system in Godot was already one of the most powerful of any game engine, but its age was starting to show (it was written 10 years ago and barely improved). The new one builds upon the strengths of the previous one but does massive improvements to features and usability. + + +### A bit of history + +Animation editing was one of the first distinctive Godot features. If you are familiar with Godot, you may already know that *any property* from *any object* can be animated or tweened. Changing sprite textures, colors, animation frames, calling functions, playing animations in other animation players, playing sounds, etc. All is done transparently by simply animating property states. + +Although this approach works really well, it started showing its age as it was not improved very much in almost 8 years. The reason for this is that the code behind animation editing was too hard-coded in general, which made it difficult to add new features or improvements. In the image below, the animation editor can be shown as it was in 2010. Nothing much has changed since: + + + + +### Rewriting from scratch + +As it has been the trend the past months, with the rewrite of the 2D editor, inspector, etc., the time has come for a new animation editor to come forward. The new code is more modular, and allows extending track editing to show custom visualization. It also has a plethora of new features that will indeed be very useful. + +With the new trend of cinematic tools and timelines coming recently to the big engines, this workflow (which was already possible) was cleaned up and made much easier and visual. + +Following is the long list of changes and improvements included in the new animation editor! + + +### New layout + +First of all, there is a new layout (keep in mind the visuals are not final, and will be further refined by our UI styling contributors before 3.1). + +The old layout wasted a lot of horizontal space in buttons that were seldom used. Buttons in large groups are, in general, not a very helpful usability convention so the whole layout was confusing. Some useful menus (such as add track) were hidden in the clutter, and the animation name had only a bit of space to show itself. + +Some buttons were unnecesary, such as move up/down, which remained from the ages when Godot did not support drag and drop. + + + + +The new layout is much simpler and has moved most functions to menus. Only the really important buttons remain visible. The animation length and loop options are now together in the timeline, as well as the button to add tracks. + + + + +The step field was confusing, so it was renamed to a snap button. Snapping can now be toggled on or off. + +### New track workflow + +Besides the usual workflow of inserting keys (and creating tracks) from the inspector, new tracks can be created directly from the Add Track menu. This not only provides an alternative workflow, but works much better for non-property tracks, such as *Call* tracks and the new *Bezier*, *Audio* and *Animation* tracks. + + + + + + +Keys can also be inserted at any position in the timeline by simply right-clicking over the track at a given position in time. + +Adding a Call track and calling a function, as an example, is a lot more intuitive: + + + +Just trust this new menu, as it will always lead you through the right dialogs to get your tracks set up in no time! + +### Key editing in inspector + +The old layout had a small sub-window where key values as well as transition curves could be edited for each key. Most users did not even know this feature existed due to the huge amount of clutter. + +In the new animation editor, just clicking a key will allow editing it in the inspector: + + + + + +### Key previews + +Most types of keys can have their values previewed directly in the track, thanks to track editor plugins. Godot comes with a bunch of built-in ones for most key types. + +As an example, editing animation frames is a lot more friendly now: + + + +As well as many other key types, such as: + +* Boolean tracks +* Color tracks (which show colors and transitions) +* Call tracks (which show the function and arguments) +* Stream playback (shows a stream preview) +* Volume DB (shows a gradient with the volume) + + + + + +### Bezier Tracks + +To be more in line with other software and thanks to the work done by Bojidar Marinov on set/get indexing for tweens, it is now possible to create Bezier tracks. + +These are normal tracks and look like regular tracks that edit a single float component: + + + + +But with the push of a button, it is possible to edit the Bezier curves directly in the integrated bezier editor! + + + + +Related tracks in the same object will appear in the background for reference, and switching between them is easy with the menu on the left. + + +### Animation and Audio tracks + +Two new track types were added: *Animation* and *Audio*. Animation tracks need to point their path to an *AnimationPlayer* node (must be different from the current one). Audio tracks need to point to an *AudioStreamPlayer* node (can be *AudioStreamPlayer*, *AudioStreamPlayer2D* or *AudioStreamPlayer3D*). + +Audio tracks work very similar to a DAW. Just draw audio resources into the animation track and it will play them back. Editing their start and end offset is allowed, to better adjust the sound to the rest of the animation. + + + +This workflow is very smooth, and previews of the audio are rendered in a thread to not obstruct your work, just like in a real DAW! + +For animations, just insert current animation keys in the same way as before, but now they will be previewed with full length on the timeline. + +Added to that, the new tracks are designed to work better with seeking, so you can seek (via code or editing) to any point of the master animation, and both audio and sub-animations will start from the right offset: + + + + +To also help with this workflow, the currently pinned animation editor is displayed in the Scene Tree: + + + + + + +All this together makes Godot's built-in animation support the most powerful tool for in-game cinematic creation and editing. This goes in-line with Godot's philosophy of having a single, powerful and well designed tool instead of several ones duct taped, like in other engines. + + +### Track grouping and filtering + +This has been a long-standing request. It is now possible to see tracks grouped together by object. This makes complex animations with lots of tracks much less confusing. + + + + +It is also possible to filter tracks with the push of a button. When filtering is enabled, only tracks selected in the Scene Tree dock will appear editable. + +### Track copying and pasting + +Another long standing request is the ability to copy and paste tracks between animations. this has been made much easier with the new copy/paste menu: + + + + +### Capture Mode + +The last significant feature introduced in the animation editor is *capture* mode for property tracks. When these tracks are set to *capture*, the current property value in the object is remembered. From there onward, it will blend with the first animation key found: + + + + +The main use of this feature is for animating UI components (as in, menus sliding in an out, buttons becoming bigger or smaller, etc.) without having to resort to tweens. Still, it can be used with anything else, so I'm sure that other creative uses will arise. + + +### Future + +Please test this code well (it's now available on GitHub HEAD) so all the bugs can be ironed out before Godot 3.1 is out! + +Some features were left out due to lack of time, but may be implemented later, such as a global track (for ease of selecting long list of keys). Others are still in the works (like proper auto-keying). + +And again, please remember that Godot is made with love for everyone! If you haven't yet, please consider [donating and becoming our Patron](https://www.patreon.com/godotengine)! \ No newline at end of file diff --git a/collections/_article/godot-gets-csg-support.md b/collections/_article/godot-gets-csg-support.md new file mode 100644 index 0000000000..f1a3e0b045 --- /dev/null +++ b/collections/_article/godot-gets-csg-support.md @@ -0,0 +1,105 @@ +--- +title: "Godot gets CSG support" +excerpt: "After years of discussion on how to implement CSG, Godot finally gets suport for it. This implementation is simple, but makes use of Godot's amazing architecture to shine." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5ae/4d0/8c6/5ae4d08c674b5082905650.png +date: 2018-04-28 00:00:00 +--- + +After years of discussion on how to implement CSG, Godot finally gets suport for it. This implementation is simple, but makes use of Godot's advanced architecture to shine. + +### Wait, what is CSG? + +CSG stands for "Construtive Solid Geometry", and is a tool to combine basic (and not so basic) shapes to create more complex shapes. In the 3D modelling software, CSG is mostly known as "Boolean Operators". + + + +### Why is CSG relevant? + +The aim of CSG in Godot is for it to be used in level prototyping. This technique allows to create simple versions of most common shapes by combining primitives. Interior environments can be created by using inverted primitives instead. + +CSG is a vital tool for level design (and level designers in companies) as it allows to test gameplay environments without modelling a single triangle. Unreal has always offered similar boolean CSG, while Unity has recently acquired ProBuilder (which is a different type of tool, but still aimed at prototyping level geometry). + +For developers, creating 3D art is a time consuming process. For indies or small companies, it may even involve outsourcing to third party artists. With CSG, a game can be developed almost entirely without relying on 3D environment artists, only for that content to be filled in the end when gameplay is already working. + + + +### How does it work? + +Godot provides a bunch of Primitive nodes: + +* **Sphere** +* **Box** +* **Cylinder** (can be used as Cone) +* **Torus** (donut shape) +* **Polygon** (can be drawn in 2D and then extruded) +* **Mesh** (can use any custom geometry) + + + + + +Each of these operates on the parent CSG node, in order. Supported operations are: + +* **Union**: Geometry of both primitives is merged, intersecting geometry is removed +* **Intersection**: Only intersecting geometry remains, the rest is removed +* **Subtraction**: The second shape is susbtracted from the first, leaving a dent with it's shape. + + + + +##### Process order + +Every CSG node will first process it's children nodes (an their operation: union, intersection substraction), in tree order and apply them to itself one after the other. + +There is a special CSGCombiner node that is pretty much an empty shape. It will only combine children nodes. It's used for organization mostly. + +##### Polygon and lofting + +The CSGPolygon node is very convenient, a Polygon is drawn in 2D (in X,Y coordinates), and it can be extruded in the following ways: + +* **Depth**: Extruded back a given amount +* **Spin**: Extruded while spinning aroud it's origin. +* **Path**: Extruded along a Path node. This operation is commonly called *lofting*. + + + +##### Custom meshes + +Any mesh can be used for CSG, this makes it easier to implement some types of custom shapes. Even multiple materials will be properly supported. There are some restrictions for geometry, though: + +* It must be closed +* It must not self-intersect +* Is must not contain internal faces +* Every edge must connect to only two other faces + + + +Make sure CSG geometry remains relatively simple, as complex meshes can take a while to process. + +##### A note on performance + +If adding objects together (such as table and room objects). It's better if this is done as separate CSG trees. Forcing too many objects in a single tree will eventually start affecting performance. Only use binary operations where you actually need them. + +### Godot CSG Implementation + +As many libraries seemed to exist for this, I decided to pick one and put it in Godot and implement it over a weekend. Of course, this unfortunately did not work well. A few things stopped me. Pretty much every library I found was: + +* Under GNU GPL or GPL, making it incompatible with Godot +* Using really crappy algorithms such as voxel or BSP, making them inefficient. +* Designed for 3D modelling or mathematics, so they used very tuned algorithms dealing with avoiding precision errors. + +Nothing was really meant for games. This led me to write a custom one for Godot, with focus exclusively on performance. + +The current implementation is really simple. It does brute force clipping of triangles without relying on vertex IDs, or isolating edges to detect interior faces. Instead the implementation in Godot does triangle-triangle raytracing to detect which halves ended up inside the intersection. + +This is expensive per se, but it's optimized by doing a pre-aabb intersection and balanced binary trees to minimize the amount of ray tests. As a result, the performance is really good. + +As the implementation is pure brute force, some visual artifacts may rarely appear in some cases if you look well, but truth is that they don't have any practical impact as CSG in Godot is mostly meant for level prototyping. In fact I'm sure for some types of game CSG could easily be usable in production. + +### Future + +The main missing feature now is the ability to export the scene to a 3D modelling software (likely via GLTF2), so the process of replacing CSG art by final art can be done by a professional artist. This will be added soon. + +Please test well! And remember that we make Godot with love for everyone. If you are not already, please consider [becoming our patron](https://www.patreon.com/godotengine), so we can continue doing this for you! \ No newline at end of file diff --git a/collections/_article/godot-gets-mobile-vulkan-renderer.md b/collections/_article/godot-gets-mobile-vulkan-renderer.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/collections/_article/godot-gets-new-animation-tree-state-machine.md b/collections/_article/godot-gets-new-animation-tree-state-machine.md new file mode 100644 index 0000000000..92065acf38 --- /dev/null +++ b/collections/_article/godot-gets-new-animation-tree-state-machine.md @@ -0,0 +1,94 @@ +--- +title: "Godot gets new Animation Tree + State Machine" +excerpt: "After a long time coming, and as part of this trend of modernizing many old godot subsystems, the animation tree has been rewritten from scratch and it's now brand new, with plenty of new features." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5b3/2ca/354/5b32ca3546bbf512292209.png +date: 2018-06-26 00:00:00 +--- + +After a long time coming, and as part of the trend of modernizing many old Godot subsystems, the animation tree has been rewritten from scratch and it's now brand new, with plenty of new features. + +This was one of the main missing features in Godot, which makes it now much more apt for complex 3D games. + +### Completely modular design + +There is a new node, AnimationTree. It does nothing by itself, so a tree root needs to be set to it: + + + + +There are plenty of nodes to put in the tree, but only a few root nodes are valid by default: + +* **Animation** (a regular animation) +* **BlendTree** (A blend tree, similar to the previous AnimationTreePlayer) +* **BlendSpace1D** and **BlendSpace2D**, for visual blend spaces. +* **StateMachine** (a state machine) + +Save for animation, any of those nodes can contain other types of nodes. Detail is as follows: + +### Blend Tree + +This node is similar to the old AnimationTreePlayer. It's a run of the mill animation blend tree. Nodes +have inputs and outputs and can be blended. This new implementation has a lot of visual feedback, though: + + + +Animations show their progress with a proper bar, and active wires become blue. + +It is also possible to use blend spaces, state machines and even other blend tree as sub-nodes. In the example below, two state machines are blended via a Blend2 node, with filters set. This way, a functionality similar to state machine layers (from other engines) can be achieved easily. + + + + + +### Blend Space 1D and 2D + +With the help of karroffel, both 1D and 2D blend spaces are supported in Godot. + + + + + + +For the 2D version, an automatic triangulation option is set by default (which can be changed to manual if required). Other engines hide it by default, but we believe it should be better that users see how blending happens behind the scenes (As well as having the freedom to change it ): + + + + + + +### State Machine + +Finally, Godot introduces a state machine. This state machine is rather simple but very efficient, and relies on the concept of travel. + + + + + +Conditions to change states are not supported, but can be easily scripted by adding scripted transitions (we'll see in the future whether this is worth adding to the core or can remain an extension). + +### Custom Blend Nodes + +You can add your own custom blending logic with the new Godot API, even writing your own state machine. The new API is very easy to extend and use: + + + +### Root Motion + +It is also easy to set a track as root motion. If set as such, a transform with the motion for the frame can be obtained and used as well. A new node RootMotionView was added to aid in debugging root motion. + + + + + + +### Compatibility + +The old animation system (AnimationTreePlayer) has now been deprecated and will be removed in future versions. By the time, we will add a compatibility API so they get converted to the new system. + +### Future + +This lays the foundation for a new animation system, which will hopefully keep being worked on and improved over time. + +As always, everything is done for everyone with love, so again please consider becoming [our patron](https://www.patreon.com/godotengine)! \ No newline at end of file diff --git a/collections/_article/godot-gets-new-filesystem-dock-3-1.md b/collections/_article/godot-gets-new-filesystem-dock-3-1.md new file mode 100644 index 0000000000..62436c4453 --- /dev/null +++ b/collections/_article/godot-gets-new-filesystem-dock-3-1.md @@ -0,0 +1,37 @@ +--- +title: "Godot gets a new FileSystem dock for 3.1" +excerpt: "Godot's FileSystem dock gets an improved tree view mode with files included in the tree, with thumbnails. This makes it much easier to go through project files from a single dock. Various improvements are also done to the favorites usability, right-click menu and the split view mode." +categories: ["progress-report"] +author: Gilles Roudiere +image: /storage/app/uploads/public/5ba/4cd/937/5ba4cd9370adf233240214.png +date: 2018-09-21 10:53:56 +--- + +Before anything else, we would like to thank our long-time sponsor [Gamblify](https://www.gamblify.com) for having donated this new feature to the community. Their involvement and their constant support to make this engine better are deeply appreciated. + +For the upcoming 3.1 release, Godot gets a brand new FileSystem dock. Files, not only folders, are now displayed directly in the tree view : + + + +This new display, which can be switched with the older one with a button on the top of the dock, avoids splitting the dock in two areas. This allows a more compact interface, which also lead us to reconsider the default layout for the editor. As you can see, more space is now available to the inspector, reducing the scrolling needed there: + + + +## Features + +Amongst a set of more minimal improvements, this new FileSystem dock features several things: + +- Files can now be marked as favorites, not only folders. +- Complete drag & drop support, including dragging files and folders into the favorites section: + +- Type icons next to each file name. For textures and materials, this icon is replaced by a mini-thumbnail of the resource: + +- A search field, to filter entries in the tree: + +- A right-click menu, to handle files exactly as in the file list. +- The "Mark as favorite" button has been moved to a menu entry, found when you right-click files or folders. +- The "Find current scene in files" button has been moved to a menu entry, when right-clicking on a scene tab. + +We hope you will enjoy this new FileSystem dock. We are waiting for your feedback! + +*Note: this new feature is outside the scope of the current feature freeze, since it has been on the roadmap and worked on since before the feature freeze took effect.* \ No newline at end of file diff --git a/collections/_article/godot-gets-new-inspector.md b/collections/_article/godot-gets-new-inspector.md new file mode 100644 index 0000000000..5794a2c544 --- /dev/null +++ b/collections/_article/godot-gets-new-inspector.md @@ -0,0 +1,97 @@ +--- +title: "Godot gets a new Inspector" +excerpt: "Work is ongoing to completely overhaul Godot inspector. This was a pending assignment for me since even before Godot was open sourced but, as always, other issued had priority." +categories: ["progress-report"] +author: Juan Linietsky +image: /storage/app/uploads/public/5b0/09e/0c2/5b009e0c2cabd079105425.png +date: 2018-05-19 00:00:00 +--- + +Work is ongoing to completely overhaul Godot inspector. This was a pending assignment for me since even before Godot was open sourced but, as always, other issued had priority. + +Most of the work is currently done, only pending bugfixes and visual improvements by our design focused contributors. + +## The old inspector + +Godot grew organically. At the beginning, it made sense to make the inspector using the Tree control. For the few special types, a pop-up would be used instead. For sub-resources, editing would also go into a separate view. + +There was not much of anything and it more or less did the job, so it kind of made sense at the time (image below: Godot circa 2008): + + + +The inspector grew and became more complex over time, but it always remained tree-based (image below: Godot circa 2011): + + + +## And now.. the NEW inspector! + +After a long wait of almost 10 years, there is now a new inspector. Functionality-wise it's complete. It just needs polish and love from the visual design contributors until 3.1 is out. It solves several old problems and introduces several new features! + + + +Here's all the new features that come with it: + +#### Control-based instead of Tree + +The new inspector is Control based. All editing is done via controls instead of tree cells. This allows for much finer grained improvements in usability. It also allows writing custom plugins to customize the looks, like in the image below: + + + + +#### New Spin-Slider for numerical editing + +A new Spin-Slider (mix of SpinBox and Slider) was added for numerical entry. It alows: + +* Editing values in absolute range (via slider) +* Editing values in relative range (via spin, just drag it from left to right) +* Editing values numerically (simply click it and enter a numer) + + + +When in integer editing mode, the slider disappears and the classical up-down arrows will appear: + + +#### Multiple field editing for vector types + +Properties of types such as Vector3, Vector3, Transform, etc. can now edited and visualized directly. Many fields are exposed as a single property. + + + + +#### Sub-Resource editing within the same inspector + +One of the biggest usability hurdles in Godot was the fact that sub-resources would go to a separate inspector. In many types of nodes (Mesh, Particles, etc), editing sub-resources was truly a hassle. + +This no longer applies to the new inspector. Sub-Resources wil open within the same list of edited properties: + + + +It also makes animation easier, as any sub-resource property can be animated transparently. + +#### Named layers + +Besides the boxes, the list of layers now appears in a proper drop down, making it easier to select them by name: + + + + +#### Proper Array and Dictionary editing + +With the old inspector, editing arrays and dictionaries was more or less a hack. A new proxy object was created that would edit it, which requiered going into a separate inspector. Undo and Redo also did not work well on it, given the hacky nature. + +Currently, editing them is done properly and without even going to a sub-inspector. Here is an example of two arrays, of different types, being edited at the same time. Arrays can be collapsed to save vertical space. + + + +Same goes for dictionaries, which can be visualized and edited within their parent objects: + + + + +## Future + +The new inspector will also result in many improvements on current features, such as animation editing, visual scripting, visual shader editing, etc. Many of those are being reworked for 3.1 and will see their usability and features improved. + +Make sure to test well and report all the issues you can, so the new inspector is as stable as possible for the upcoming Godot 3.1. + +As always, remember that Godot is done with love for everyone who enjoy making games. If you are not already, please consider becoming [our patron](https://www.patreon.com/godotengine). \ No newline at end of file diff --git a/collections/_article/godot-getting-more-languages.md b/collections/_article/godot-getting-more-languages.md new file mode 100644 index 0000000000..838c0b146b --- /dev/null +++ b/collections/_article/godot-getting-more-languages.md @@ -0,0 +1,68 @@ +--- +title: "More programming languages in Godot, want to help?" +excerpt: "There is a common misundertanding in the industry about us, Godot devs, trying to reinvent the wheel because we like it. This could not be further away from the truth." +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/57a/b73/701/57ab73701f653339027447.jpg +date: 2016-08-10 00:00:00 +--- + +## Why more languages, isn't GDScript enough? + +There is a common misundertanding about us in the industry: Godot devs, always trying to reinvent the wheel because we like it. This could not be further away from the truth. + +The reality is that we are extremely demanding with our requirements from third party solutions and it just happens that very often, even if a library, language, etc. is very popular, it does not satisfy our needs. This was the case of third party scripting languages such as Lua, Python, Squirrel, etc. + +When we originally made Godot, we were completely certain that we wanted our main scripting language to be dynamically typed due to the high accessibility this provides. We understood that most of the code written for a game is not performance critical, and that the C++ part of the engine already covers most of the critical parts, so we originally went for Lua, and then for Squirrel (while trying Python in the process). + +Unfortunately, we had many problems with those languages. Binding code was always large, complex and prone to bugs. True multi-threading (with a stack per thread, but sharing memory) was not supported, and vector types had to be created with custom userpointers, which provided much slower performance than built-in types. Added to that, we could never completely eliminate the stalls related to the garbage collector. + +GDScript was born as a way to make all these problems go away. When users write code in GDScript within the IDE, everything simply "just works" and you have the added value of live code completion. None of this could have been made with a third party language. We tried, we became experts at it, but it just didn't work out. + +Because of this, **GDScript will always be the main supported language**, and our recommended choice for all Godot users. + + +## Why other languages, then? + +Even though we will always recommend new users to go the GDScript route, because we know it's the least hassle option, we understand that developers have different needs and experiences, and that believing in "one size fits all" is a mistake. That's why we are working on the support of C# and visual scripting for the upcoming Godot 2.2. + +### Why C#? + +In the case of **C#**, there is a huge amount of love towards this programming language, which is expected due to the main designer being the same guy who created Object Pascal (which was very popular in the 90s with Borland Pascal and later through Delphi). + +Truth is that Mono is very well made, has excellent, modern binding extensions (the complete opposite to Java/JNI) and supports multi-threading just fine. As a result, it should integrate smoothly into Godot. The only reason we did not want to go this route in the past was due to license restrictions, but this ceased to be a problem a few months ago when Microsoft acquired Xamarin and relicensed Mono under the MIT license. + +The main benefit of supporting C# is that, all of a sudden, Godot will become a more-than-tempting option to the indie and corporate cultures who are used to products supporting this language. This should greatly help us reach potential users who might have been initially puzzled by having to *learn* GDScript (though we still guarantee that any programmer can pick up GDScript in less than an hour). + +This is, however, not the main reason behind our intention to support this language. As always, we want to implement the features that our community wants the most, and C# support is definitely one of the most recurrent topics. We also believe that it will provide a high performance alternative to GDScript without having to compile Godot manually for C++, and a statically typed language for the developers allergic to duck typing. + +To clarify things: since the Mono runtime is relatively heavy, and many Godot users will prefer to stick to GDScript, we intend to provide the Mono-enabled version of Godot as a **separate download**. This means that users will have the choice to use Godot with GDScript only, or GDScript and Mono. + +### Why Visual Scripting? + +Another language currently being added to Godot is **VisualScript**, our take on visual programming. We are using an approach similar on the surface to Unreal's Blueprint, but pretty different under the hood. + +As we have seen so far many Godot users and other developers puzzled about Godot adding this functionality, we want to make very clear that it is not our intention to replace GDScript or traditional programming for a visual approach. + +To make it clearer, it is *not* our belief that forcing programmers to write code with visual blocks will result in a more efficient workflow. We know other game engines and solutions try to sell you this point of view, but rest assured that this is not our view or intention. We stand by programming and still believe it's the best. + +So then, again, why visual scripting? Our goals with it are the following: + +* Provide a way for non-programmers to experience what developing in Godot feels like, by ensuring they have a way to manipulate their game's logic. +* Allow programmers to set up their scenes, AI, etc. in a way they can expose the coarse parameters and logic to level designers or game designers. This way, they can do tweaks without bothering programmers. +* Allow programmers to expose how data is organized in a visual way. Godot's VisualScript has so much flexibility in how the graph flows that it allows creating dialogue trees, coarse game flow, event handling, etc. with small effort. + +Please understand it as just an extra tool, not as a replacement to programming. It will be possible to use both GDScript and VisualScript as complementary tool in a same project. + +## Binding new languages + +There currently is a lot of demand for additional languages, such as Java, Haxe, Swift, Object Pascal, etc. As Godot 2.2 will focus on new languages, this a great time to help us develop and improve the binding API. Of course it may seem like a challenging effort. + +Officially, our supported languages for now will be GDScript, Mono, VisualScript and C++. If you want to help integrate another language, you should first of all contact us (see contact info at the bottom of the site or use IRC: [#godotengine-devel on Freenode](https://webchat.freenode.net/?channels=godotengine-devel)). The process to add new languages is more or less the following: + +1. **Re-create Godot's basic types in your new language**: These are types such as `Vector3`, `int`, `float`, `String`, etc. Many of these are usually provided already. +2. **Create a module**: A C++ module that creates binding code needs to be done ([creating modules in C++ is well documented](http://docs.godotengine.org/en/latest/reference/custom_modules_in_c++.html)). The entire exposed Godot API can be accessed via the static functions in `ObjectTypeDB`. +3. **Generate binding code** in your new language that accesses the exposed functions in the `MethodBind` class (there is one for each exposed method). +4. **Create a `ScriptLanguage`** class and supply the neccesary methods exposed for debugging, profiling, etc. You can supply symbols, code completion helpers, etc. if this language is meant to be edited inside Godot. + +Again, as this process is not fully streamlined yet, we encourage you to get in touch with us if you want to do this effort. \ No newline at end of file diff --git a/collections/_article/godot-google-summer-code-2018.md b/collections/_article/godot-google-summer-code-2018.md new file mode 100644 index 0000000000..9209a88ca1 --- /dev/null +++ b/collections/_article/godot-google-summer-code-2018.md @@ -0,0 +1,44 @@ +--- +title: "Godot in Google Summer of Code 2018" +excerpt: "Godot has been accepted into the Google Summer of Code program in 2018. This summer we will have 5 students working on new features to the engine." +categories: ["progress-report"] +author: George Marques +image: /storage/app/uploads/public/5ad/f38/7a8/5adf387a8d4f0692142419.png +date: 2018-04-24 11:04:00 +--- + +For those who might not be aware, the Google Summer of Code is a yearly program that brings students from all over the world into open source projects. The students have the opportunity to get involved into a real software development process, while the organizations can welcome a new contributor working on a valuable feature, potentially becoming a regular after the summer is over. + +We developed a [list of ideas](https://github.com/godotengine/godot-roadmap/blob/master/GSOC-2018.md) to apply to the program (though students are free to come with their own proposals). Everything was made in a bit of a rush and without many announcements since we were quite busy with Godot 3.0 release and a few big events in the schedule. In February 12 we [got the good news](https://twitter.com/reduzio/status/963113170301865985) that Godot was accepted as participant organization. + +This is the first year Godot is participating in the program and we got the chance to accept five student projects that will be developed from May to August. The projects were just announced publicly and we are looking forward to see the development of the features. + +We hope that the Godot community will give a warm welcome for these new contributors that will be working with us during the summer. I'm sure that if the students feel the good vibes from the community they'll hang around and keep contributing to our engine. + +Without further ado, let's go through the list of accepted proposals: + +## Support for video decoder modules with GDNative + +This project will be about creating an interface into GDNative so custom video decoders can be added without the need of recompiling the engine. It'll enable Godot to support several video formats that are hard to integrate because of patents or licenses, while also avoiding the bloat in the base engine for those who don't need it. + +[Anish Bhobe (KidRigger)](https://github.com/KidRigger) will work on this project with the help of [karroffel](https://github.com/karroffel) and [Hein-Pieter van Braam (TMM/hpvb)](https://github.com/hpvb). + +## WebRTC support for multiplayer games + +The proposal by Brandon Michael Makin will add support for the WebRTC protocol into Godot's high-level network layer. This will make possible to create multiplayer games in the HTML5 platform among other benefits. [Max Hilbrunner (mhilbrunner)](https://github.com/mhilbrunner) and [Fabio Alessandrelli (faless)](https://github.com/faless) will help him in this endeavor. + +## GearVR and Daydream support + +With the help of [Bastiaan Olij (Mux213)](https://github.com/BastiaanOlij), who added the AR/VR system into Godot, [Paritosh Sharma](https://github.com/Paritosh97) will extend the system to support two mobile VR platforms: Samsung's GearVR and Google's Daydream. + +## Support for MIDI playback + +Daniel Matarov proposal's include the development of a MIDI bus, similar to Godot's audio buses, along with a sampler to allow the playback of MIDI songs. He'll be mentored by [Gilles Roudiere (Groud)](https://github.com/groud), [Marcelo Fernandez (marcelofg55)](https://github.com/marcelofg55), and [myself](https://github.com/vnen). + +## TSCN exporter for Blender + +While [already in development](https://github.com/godotengine/godot-blender-exporter), the plugin that exports Godot scenes directly from Blender is still in its infancy. With the help of [Geoff (sdfgeoff)](https://github.com/sdfgeoff), who's already improving the plugin, and [Juan Linietsky (reduz)](https://github.com/reduz), the student [Jiacheng Lu](https://github.com/Jason0214) will further work on it to get into a fully usable state. The exporter will help the workflow by removing the intermediary formats, such as Collada and glTF, so the output can be specifically tailored for Godot's needs. + +---- + +We from the Godot team want to thank Google for this great program that bridges the connection from universities to open source projects. We also want to give a big welcome for the students and wish them the best of luck. Hopefully we all will get great things from this experience. Now let the work begin! \ No newline at end of file diff --git a/collections/_article/godot-google-summer-code-2019.md b/collections/_article/godot-google-summer-code-2019.md new file mode 100644 index 0000000000..1e7eed3c91 --- /dev/null +++ b/collections/_article/godot-google-summer-code-2019.md @@ -0,0 +1,18 @@ +--- +title: "Godot in Google Summer of Code 2019" +excerpt: "Godot will take part in the Google Summer of Code for the second time in a row, and we are thrilled at the opportunity to mentor students to work on interesting projects for the Godot community." +categories: ["progress-report"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5c7/67d/8c6/5c767d8c62621713488685.png +date: 2019-02-27 12:08:27 +--- + +Google has accepted our application as participant organization in [Google Summer of Code](https://summerofcode.withgoogle.com) (GSoC) 2019! It's our second participation in the programme, after [GSoC 2018](/article/godot-google-summer-code-2018) where we had 5 students working on [exciting topics](/article/gsoc-2018-progress-report-1). Here's our **[organization page](https://summerofcode.withgoogle.com/organizations/6553848640962560/)** for 2019, and our [list of ideas for potential projects](https://github.com/godotengine/godot-roadmap/blob/master/GSoC/GSoC-2019.md). This list is not exhaustive, students are encourage to come with their own proposals (after having their relevance validated by core developers). + +Google Summer of Code is a yearly program that brings students from all over the world into open source projects. The students have the opportunity to get involved into a real software development process, while the organizations can welcome a new contributor working on a valuable feature, potentially becoming a regular after the summer is over. (Note: The program is called "Summer" of Code, but in the Southern hemisphere it happens during Winter. See the [timeline](https://summerofcode.withgoogle.com/how-it-works/#timeline) for exact dates.) + +Now's the time for interested students to become familiar with the engine's source code and our development workflow, get in touch with developers on IRC and use these contacts to define or refine their project proposal. + +We strongly encourage prospective students to try to start contributing on junior bug reports before the actual application deadline: we'll be more likely to pick students who have demonstrated that they can fit into our workflow. The application period goes from **March 25 to April 9**. + +See our **[organization page](https://summerofcode.withgoogle.com/organizations/6553848640962560/)** for more details on the process, how to get started contributing to Godot and how to prepare your application. \ No newline at end of file diff --git a/collections/_article/godot-has-been-renamed-godette-engine.md b/collections/_article/godot-has-been-renamed-godette-engine.md new file mode 100644 index 0000000000..35a5ce0692 --- /dev/null +++ b/collections/_article/godot-has-been-renamed-godette-engine.md @@ -0,0 +1,56 @@ +--- +title: "Godot has been renamed to Godette Engine" +excerpt: "After months of internal debate, we have decided to deal once and for all with a hot topic and the source of much criticism. Godot is being rebranded in order to gain wider appeal and acceptance." +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/606/4fb/1b9/6064fb1b9a8b5692034114.png +date: 2021-04-01 00:10:00 +--- + +***Edit:** We have seen many comments on our April Fool's joke. We strive to make the Godot community, and game development in general, a welcoming place for everyone. By not understanding the various ways in which our joke could be interpreted we have failed in this goal.* + +*The Godette character was made [years ago](https://twitter.com/reduzio/status/958305883976536064). It was not created for this joke. The joke itself was intended to poke fun at a very vocal minority of users who think that our robot logo isn't "professional", thus the joke was us pretending to be switching to an even more playful character.* + +*Having said that: our intention does not matter if so many people interpreted the article in the way they did. We apologize for the oversight. We strive to do better in the future.* + +---- + +After months of internal debate, we have decided to deal once and for all with a hot topic and the source of much criticism. Godot is being rebranded in order to gain wider commercial appeal. + +### Epiphany + +It may have taken us a long time, but we finally understood and accept that Godot is about reaching *wider audiences*, about making something ***ultimate***, about going be beyond what ***any other game engine*** has ever attempted. + +We thought we had ***everything***. Passionate contributors, an amazing community, and dedicated leadership. Yet, something ***kept getting in our way*** and we could not figure what it was. Sleepless nights and months of ~~watching anime during lockd~~heated debate were required for us to achieve epiphany, the realization that something had to change. + +### The Godot name + +How are we supposed to work on something ~~the English speak~~no one knows how to pronounce? Is it Go-Dot, Go-DOUGH? GOH-do? Robot? Not even the original authors have a clue when you ask them. + +Additionally, we realized that a big problem of Godot as a project name is that it's simply ***not cute***. To attract wider audiences, a different name must be found, a more marketable one which speaks to a broader public. + +### The Godot logo + +Since Godot was open sourced, we received countless amount of criticism from a ~~small vocal min~~majority of the community, pointing out the lack of professionalism of the Godot logo. Have you ever read comments from community members like these? + +- It doesn't look like the logo of a commercial game engine. +- I would not pay for something with this logo. +- The robot scares me; I can't sleep at night. +- Uh, I thought the original logo was a guy's head popping out of a castle tower, now the new one does not even make sense. +- I'm afraid of clowns. + +Yes, we did too. They are all over the place. They are the writing on the wall we would refuse to see. + +### The NEW branding + +After weeks of consultation with ~~Reddit users~~[**professional marketing experts**](https://twitter.com/reduzio/status/1367975083562655745), it was decided to rebrand both Godot and its logo to convey a more professional branding. From now on, the project will be known as **Godette Engine** and the new logo will reflect this: + + + +We'll now use this branding for the engine, and our website is hosted at [**https://godetteengine.org**](https://godetteengine.org). + +Our official Twitter account has also been moved over to [@godetteengine](https://twitter.com/godetteengine) so make sure to give it a follow. + +### More changes coming + +Also, in order to make the engine more commercially appealing, we are evaluating other changes, such as moving the engine to a premium *shared revenue* model, *increasing* the download size to a few gigabytes, and making any kind of help or support *paid*. A bright future is coming for our ~~sharehold~~community. We hope to be able to tell you more very soon (probably on April 2, since it's now April 1). \ No newline at end of file diff --git a/collections/_article/godot-history-images.md b/collections/_article/godot-history-images.md new file mode 100644 index 0000000000..4242f386b7 --- /dev/null +++ b/collections/_article/godot-history-images.md @@ -0,0 +1,32 @@ +--- +title: "Godot history in images!" +excerpt: "How does more than a decade of engine development look like?" +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/57f/215/a0e/57f215a0e3c2a359176299.png +date: 2014-01-15 00:00:00 +--- + +## A trip down Godot Memory Lane + +Godot was not always called Godot, it went through many (horrible) names, in the following order: + +* Larvotor +* Legacy +* NG3D +* Larvita +* Larvita2 +* Larvita3 +* Godot + +In fact, Godot was just a code-name for what would be something else, a more general purpose engine with a proper UI instead of a set of assorted tools. We knew it would take a long time, so we used a name based on a play by Samuel Becket to represent that feeling. Eventually the name would change to something with a connection to our home country, Argentina. + +In a bizarre twist of fate, at some point and well into the development of the engine, we played a video game with a character that formed that connection (bonus points to anyone who figures it out), so the engine is also named in honor to that. This is good, because the original Godot was never supposed to arrive (well, that’s one interpretation...). + +## History in pictures + +Enough talk. So, how does more than a decade of engine development look like? Like a mess, obviously! (wait for images to load if it’s taking too long!) + + + +We hope that future screens in the next years will be of your games, not ours! \ No newline at end of file diff --git a/collections/_article/godot-jam-starts-now-theme-temperature.md b/collections/_article/godot-jam-starts-now-theme-temperature.md new file mode 100644 index 0000000000..b042cc9fbb --- /dev/null +++ b/collections/_article/godot-jam-starts-now-theme-temperature.md @@ -0,0 +1,46 @@ +--- +title: "The Godot Jam starts now, theme: Temperature" +excerpt: "With a slight delay, the Godot Community Game Jam is now starting and we can announce the theme that was elected by the community: TEMPERATURE! + +The jam starts today (Friday 15 June) at 19:30 UTC and will end on Monday 18 June at 23:59:59 UTC. Have fun and good luck!" +categories: ["events"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5b2/41b/605/5b241b605209f362633139.png +date: 2018-06-15 19:30:00 +--- + +With a slight delay(1), the [**Godot Community Game Jam**](https://itch.io/jam/godotjam062018) is now starting and we can announce the theme that was elected by the community: + +**TEMPERATURE** + +That's it! The jam starts today (Friday 15 June) at 19:30 UTC and will end on **Monday 18 June at 23:59:59 UTC**. + +## Rules + +The rules are detailed on the [jam page](https://itch.io/jam/godotjam062018), but let's mention them here too for clarity: + +- Theme: **TEMPERATURE** +- The theme can be interpreted freely, but keep in mind that your interpretation should be understandable if you want to get points for it. +- The game should use Godot Engine :) +- Contestants can partake alone or as a team. Reusing existing code and assets is allowed. +- Source code under [proper open source licenses](https://choosealicense.com/) should be provided for each game + +## Rating + +Once the jam ends, everyone with an [itch.io](https://itch.io) account will be able to play and rate the games. The categories used for evaluating games will be: + +- *Theme interpretation* +- *Gameplay* +- *Graphics and sound* + +Those three criteria are averaged into the *Overall* criterion, which is used to determine the jam winners. The winners in each category will also get their spotlight :) + +## Prizes + +Like many jams, the main purpose of the Godot Jam is to encourage users to actually make games and be proud of their achievement. And like many jams, the main outcome of Godot Jam is *exposure* \o/ and experience (and a wealth of open source projects to play with and learn from). + +But we may have some goodies for the jam winner and category winners, and maybe some more... Stay tuned for a later announcement :) + +Have fun and good luck! + +(1) Reportedly due to some project manager enjoying a leisurely real-life time and completely forgetting that he had to announce the jam theme, only to discover one hour too late the panic that roared on the Discord group in the meantime... But those alternative facts could not be confirmed, and it's unlikely that an organization as serious as Godot Engine would have a single point of failure for such an event. \ No newline at end of file diff --git a/collections/_article/godot-joins-software-freedom-conservancy.md b/collections/_article/godot-joins-software-freedom-conservancy.md new file mode 100644 index 0000000000..e44b0668fc --- /dev/null +++ b/collections/_article/godot-joins-software-freedom-conservancy.md @@ -0,0 +1,20 @@ +--- +title: "Godot joins Software Freedom Conservancy" +excerpt: "Godot is the newest member of Software Freedom Conservancy!" +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/56c/326/ef2/56c326ef24792179061082.png +date: 2015-11-04 00:00:00 +--- + +Godot is the newest member of Software Freedom Conservancy! + +Today we want to publicly announce that [Godot has joined Software Freedom Conservancy](https://sfconservancy.org/news/2015/nov/04/godot-joins) as a member! Conservancy is now our non-profit corporate home. + +Conservancy is a non-profit public charity that provides a home to its member projects that develop Free, Libre, and Open Source Software (FLOSS). Conservancy's assistance allows software developers and documenters to enjoy the benefits of nonprofit incorporation and expertise without having to independently undertake all of the effort to do it on their own. Joining Conservancy allows projects to collect donations, hold assets, and provide some liability protection for their lead developers' project-related activities. Software Freedom Conservancy, Inc. is a tax-exempt 501(c)(3) organization, incorporated in New York State. + +Ariel Manzur, core Godot developer, commented, “This is a huge step for us towards becoming a more open, rooted, and long lasting organization, to provide a more meaningful and robust contribution to the game development community, and software in general, and we're honored to have the support of Conservancy to achieve this.“ + +“We're thrilled to have Godot join Conservancy's projects,“ said Karen Sandler, Executive Director of Conservancy. “Games are an important part of the software ecosystem and freedom in this area is essential as they are often the first entry point for people to learn about software and how it works.“ + +As a result, we will soon be able to offer the possibility to ask for donations and get corporate sponsoring programs. Stay tuned! \ No newline at end of file diff --git a/collections/_article/godot-leap-motion-support.md b/collections/_article/godot-leap-motion-support.md new file mode 100644 index 0000000000..f1c494fa9b --- /dev/null +++ b/collections/_article/godot-leap-motion-support.md @@ -0,0 +1,25 @@ +--- +title: "Godot Leap Motion Support" +excerpt: "Leap Motion hand tracking support arrives with Godot 3.0.3" +categories: ["news"] +author: Bastiaan Olij +image: /storage/app/uploads/public/5b2/78c/51c/5b278c51c79b7843614393.jpg +date: 2018-06-19 12:35:32 +--- + +Support for the [Leap Motion](http://www.leapmotion.com/) sensor was added as a [GDNative plugin](https://godotengine.org/asset-library/asset/215) a few months back however full support for this sensor required changes made in Godot 3.0.3. + +With Godot 3.0.3 officially released we can now announce support for this wonderful device. The module uses Leap Motions latest LeapC libraries which are a big improvement on their older API. This new API has only been released for Windows at this point in time so there is no support for Linux and Mac yet. + +The Leap Motion sensor tracks hand and finger movement and in such offers a very natural interface. Leap Motion made the change to using their technology in the AR and VR space a year or two ago and it is a wonderful fit. Being able to use your hands directly in virtual reality is a great experience. + +**Using the Leap Motion** + +To use the Leap Motion in Godot couldn't be simpler. Just download the [Leap Motion asset](https://godotengine.org/asset-library/asset/215) from the asset library into your project. You will find several scenes inside this module that you can add that immediately set up the device. + +In a non-VR application just place the sensor node somewhere in your scene and the hands will magically appear in relation to that node. +For a VR application you should place the sensor node as a child node of your `ARVROrigin` node and turn the ARVR mode of the sensor on. It will automatically take into account that the Leap Motion sensor is attached to your HMD. + +When you select your sensor node you will see that all the properties to configure the sensor are shown: + + \ No newline at end of file diff --git a/collections/_article/godot-now-really-free.md b/collections/_article/godot-now-really-free.md new file mode 100644 index 0000000000..44dff17c6f --- /dev/null +++ b/collections/_article/godot-now-really-free.md @@ -0,0 +1,50 @@ +--- +title: "Godot is now really free!" +excerpt: "APRIL FOOLS' DAY JOKE! -- Godot goes fully FREE to follow the standards of the game development industry, including a mandatory Splash Screen of Pride, the removable of scripting languages support and of course very interesting conditions to share the profit of your work with your beloved engine developers!" +categories: ["news"] +author: Juan Linietsky +image: /storage/app/uploads/public/56f/d20/248/56fd202489c27661475944.png +date: 2015-04-01 00:00:00 +--- + +**Edit: This was of course a light-hearted joke for April Fools' Day 2015 :)** + +## Free Godot + +We have noticed a happy new industry trend amongst the major video game engines. In the interest of keeping hip with the trend, we decided to also follow suit. As of 12:01am CST today, we are very excited and overwhelmingly proud to announce that the entire Godot Engine is now **FREE**! + +You must be wondering what has changed. Truth is, Godot’s license allowed users to do anything, so it wasn’t really following the true definition of “free” which was adopted by the industry leaders. To make Godot a more viable choice in the eyes of developers, we have decided to attach strings to its freedom. + +Finally, Godot now has usage restrictions more fitting of a real-world game engine. What follows is a brief introduction to the changes we have implemented, effective immediately: + +### Splash screen of pride + +We know you are too poor to afford professional software, so we are following industry leaders and Free Godot is adding an unchangeable, mandatory splash screen. This way you can let your customers know how proud you are to be poor. + + + +### No scripting language + +You have a lot of complaints about GDScript. We hear you! Loud and clear. Every few days someone is asking for Lua, C#, *real* Python, or some other kind of scripting language that isn’t the one that we had so tightly integrated into the engine. + +Effective immediately, Godot has no scripting language. Just download the Free Godot Engine source code program directly in C++! Or better yet, you can integrate your favorite VM! + + + +### Sharing your success + +We want you to be successful, and we want to be successful right there with you. But only if you succeed. In other words, your success will never be 100% completely yours. If your game makes money, we want a small part of it. If you go out for drinks, we want a beer. The same way if you purchase a new house, we want a room there. Some kinds of success are priceless; in such cases you are not required to share. An example of this is having success with a romantic partner (as long as you don’t pay for it). + +We feel that a 10% cut of all sales is not unreasonable to ask for. Think of it as a tithe to Lord Godot. True, you don’t have a choice in the matter. But remember, the Lord Godot loveth a cheerful giver! + + + +### Democratizing development + +We also want to democratize game development. As you know, Godot Engine developers and other members of the community have always listened to your concerns, troubleshot your problems, fixed bugs you reported, implemented many of your suggestions and merged untold numbers of pull requests. This may have sufficed at one point in our history, but can continue no longer, as it’s clearly a greivous form of communism, and communism is the enemy of democracy. + +From now on, you will be free to continue sending improvements, reporting bugs, and suggesting improvements, however, we will not act of any of it without first receiving the appropriate payment (we accept cash, checque, money order, and beer). As the core development team, we will only do asmall, fixed amount of work, and then sit on our asses drinking beer until we are re-elec^H^H publish a new major version – just like real democracy. + + + +To make it clear, the new terms will being applying at 12:01am CST of **April 1st**. Of course, you can always ignore all this and keep using the MIT license, which gives you complete and absolute freedom, without any strings attached, even if it’s not trendy! \ No newline at end of file diff --git a/collections/_article/godot-oculus-quest-support.md b/collections/_article/godot-oculus-quest-support.md new file mode 100644 index 0000000000..cd717be949 --- /dev/null +++ b/collections/_article/godot-oculus-quest-support.md @@ -0,0 +1,113 @@ +--- +title: "Godot Oculus Quest support" +excerpt: "Godot works on the Oculus Quest, find out more about getting up and running if you want to play around with it early." +categories: ["progress-report"] +author: Bastiaan Olij +image: /storage/app/uploads/public/5e0/038/931/5e00389316ad1115387831.png +date: 2019-12-23 03:52:02 +--- + +Godot has been running on the Oculus Quest since early this year. We've been hard at work improving support for this amazing device. + +Late last year a new team member joined who has taken Quest support under his wing, so a special shout out to Fredia Huya-Kouadio ([m4gr3d](https://github.com/m4gr3d)), all credit goes to him. Also a quick shout out to Holger Dammertz ([NeoSpark314](https://github.com/NeoSpark314)) who has been doing a lot of testing, building examples and really pushing the limits of what Godot can do on the Quest. + +Oculus themselves started showing an interest in the work as well and have been very supportive of our efforts including providing hardware to core team members. + +The Quest seems uniquely positioned for those who enjoy working with Godot. Due to the stand alone nature of the device and it building ontop of Android you don't need a lot more to get going. Whether you are on Windows, macOS or Linux, if your machine runs Godot you can develop for the Quest. + +## Getting started + +You do need Godot 3.2 or later as various enhancements were made to the Android platform. As 3.2 is still in beta at this time download the latest beta. Keep an eye out for the announcement blog posts as you want the latest release. Also make sure to install the export templates that go with the version you download. + +Next follow the instructions in the help pages: +[Exporting for Android](https://docs.godotengine.org/en/latest/getting_started/workflow/export/exporting_for_android.html). +This leads you through installing the toolset that Godot needs to export to Android devices. + +Last but not least you will need the Quest plugin. Once Godot 3.2 is officially released we will make this plugin available in the Asset Library but to prevent confusion it is a manual download for now: [GodotVR/godot-oculus-mobile-asset](https://github.com/GodotVR/godot-oculus-mobile-asset) + +Open up Godot and create a new project. + + + +Make sure to chose the **GLES2** renderer. Due to optimisations in the Quest's GPU this backend is far better suited for the Quest. + +Copy the addons folder from the Oculus Mobile asset into your Godot project. Your project tree should looks something like this: + + + + +Now we can start building our main scene. To keep things simple we'll stick to the bare minimum. + +* We add an `ARVROrigin` node first. +* Then we add three child nodes to the origin node, one `ARVRCamera` and two `ARVRControllers`. +* Assign controller id 1 to the first `ARVRController` and rename that to `LeftHand`. +* Assign controller id 2 to the second `ARVRController` and rename that to `RightHand`. +* Finally we'll add a `MeshInstance` as a child node to our first `ARVRController` and create a box shape, resize the box so each side is set to 0.1. Now duplicate the `MeshInstance` and move it to the second `ARVRController` node. These will stand in for our controllers, we're keeping things really simple. + + + +Now add a script to the main node and add the following code: + +``` +extends Spatial + +onready var ovr_init_config = preload("res://addons/godot_ovrmobile/OvrInitConfig.gdns").new() +onready var ovr_performance = preload("res://addons/godot_ovrmobile/OvrPerformance.gdns").new() + +var perform_runtime_config = false + +func _ready(): + var interface = ARVRServer.find_interface("OVRMobile") + if interface: + ovr_init_config.set_render_target_size_multiplier(1) + + if interface.initialize(): + get_viewport().arvr = true + +func _process(_delta): + if !perform_runtime_config: + ovr_performance.set_clock_levels(1, 1) + ovr_performance.set_extra_latency_mode(1) + perform_runtime_config = true +``` + +Before we can export our project to our Quest we need to do three more things. + +First go into the project settings for our project and make sure that our main scene is the scene we run. Godot does not ask you to set this on export. + + + +Then go into the export menu and configure a new Android export. Now I'm assuming you followed the instructions in the "Exporting for Android" page I refered to at the start. If you didn't you'll have some red messages on this screen and I highly recommend you revisit that page. + +If you did we can forge ahead and make a few small changes to the export settings. +First we change the XR Mode to "Oculus Mobile VR". +Then we change our Degrees of Freedom mode to "6DOF". + + + +Now save and close the export window. + +Finally wip out your phone, when you got your Quest you needed to install an Oculus app on it and link it up to your Quest. Start the Oculus app. Press the settings cogwheel on the bottom right hand side. Select your Quest: + + + +Select "More Settings", and select "Developer Mode": + + + +Now turn developer mode on: + + + +This allows us to deploy our games to the Quest. + +Connect the Quest to your PC with the provided USB cable. Put the Quest on, it may give a few dialogs to give the PC permission to deploy apps. +Now hit the little Android button that should be visible in the top right hand side of your Godot window. It should build your game and export it to the Quest. + +The above does the bare minimum to get your project running on the Quest, it's not very exciting. Holger Dammertz has made a great toolkit for the quest that contains a lot of scenes to get help you on your way including really nice controller meshes. + +You can find his toolkit here: [NeoSpark314/godot_oculus_quest_toolkit](https://github.com/NeoSpark314/godot_oculus_quest_toolkit). + +If you want to help out with improving the plugin please join us here: [GodotVR/godot_oculus_mobile](https://github.com/GodotVR/godot_oculus_mobile). + +Last but not least, Android C# support for Godot has been added and is being tested in Godot 3.2 beta 4. We will be doing a getting started tutorial on that soon. \ No newline at end of file diff --git a/collections/_article/godot-openxr-111-plugin-release.md b/collections/_article/godot-openxr-111-plugin-release.md new file mode 100644 index 0000000000..1ed936ba63 --- /dev/null +++ b/collections/_article/godot-openxr-111-plugin-release.md @@ -0,0 +1,62 @@ +--- +title: "Godot OpenXR 1.1.1 Plugin Release" +excerpt: "Announcement for the release of the 1.1.1 Godot OpenXR plugin. The release includes several features including updated XR documentation, support for Meta Passthrough api and support for OpenXR hand tracking api." +categories: ["release"] +author: Fredia Huya-Kouadio +image: /storage/app/uploads/public/61f/18c/b23/61f18cb23063a771877721.png +date: 2022-01-26 11:15:00 +--- + +The [Godot XR contributors](https://github.com/GodotVR/godot_openxr/blob/e4af8c7b7168a7748a4e4929bc6779bb422baca7/CONTRIBUTORS.md) are delighted to release our latest version of the Godot OpenXR plugin! + +This release contains several updates to provide Godot XR developers access to the latest and greatest XR APIs and features. + + +# Download +The plugin can be retrieved from the [asset library](https://godotengine.org/asset-library/asset/986). + +**Requires Godot 3.4 or higher.** + +# Highlights +## [Updated XR Documentation](https://docs.godotengine.org/en/stable/tutorials/vr/index.html) +The [Godot XR documentation](https://docs.godotengine.org/en/stable/tutorials/vr/index.html) has been updated to better reflect the level of support that Godot provides for XR projects and consolidate the information in one location. + +We now have separate landing points for each XR API supported by the Godot Engine. + +### [OpenXR plugin](https://docs.godotengine.org/en/stable/tutorials/vr/openxr/index.html) +This plugin leverages the [Khronos OpenXR spec](https://www.khronos.org/openxr/) and is the recommended path to use when developing Godot XR games and applications. This plugin is cross-platform (e.g: Meta Quest, Valve Index, etc). + +### [Meta VrApi plugin (deprecated)](https://docs.godotengine.org/en/stable/tutorials/vr/oculus_mobile/index.html) +This plugin leverages Meta’s [VrApi api](https://developer.oculus.com/documentation/native/android/mobile-vrapi/) and only supports the Meta Quest line of devices. The VrApi api has been [deprecated in favor of OpenXR](https://developer.oculus.com/blog/oculus-all-in-on-openxr-deprecates-proprietary-apis/), and as such development on this plugin has stopped. + +Users of this plugin are recommended to migrate to the Godot OpenXR plugin. + +### [OpenVR plugin](https://docs.godotengine.org/en/stable/tutorials/vr/openvr/index.html) +This plugin leverages [Valve’s OpenVR api](https://en.wikipedia.org/wiki/OpenVR) and supports almost all PC based headsets, targeting both the Windows and Linux operating system. + +Valve has not officially deprecated the OpenVR api but is also showing a commitment to moving to OpenXR as their primary interface to SteamVR and as such users of this plugin are recommended to migrate to the Godot OpenXR plugin. + +We are however committed to maintaining this plugin. + +## Passthrough Support +This release adds support for [Meta’s Passthrough api](https://developer.oculus.com/blog/mixed-reality-with-passthrough/) enabling Godot XR developers the ability to create mixed reality games and apps for the **Meta Quest** and **Meta Quest 2**. +The documentation has been updated to provide [instructions for how to leverage this capability](https://docs.godotengine.org/en/stable/tutorials/vr/openxr/passthrough.html)! + +We’re planning to expose more capabilities of the Passthrough api in future releases, so don’t hesitate to provide feedback on desired features! + +## Meta Quest Hand Tracking Support +This release adds support for OpenXR’s hand tracking api on the **Meta Quest** and **Meta Quest 2**. + +Support for this api was already enabled for other platforms and devices, but a bug prevented it from working correctly on the Quest. The issue has been resolved in this release, making the feature available to use across all supported devices. + +The documentation will be updated shortly with instructions for how to better leverage this capability. + +## And more! +In addition to these features, this release contains several bug fixes and QoL improvements to improve the experience of Godot XR developers! + +For more details on the other changes, please consult our [curated changelog](https://github.com/GodotVR/godot_openxr/releases/tag/1.1.1). + +# Reporting Issues +For any issues encountered while using the Godot OpenXR plugin, or for any clarifications/improvements to the Godot XR documentation, feel free to open a [github issue under the Godot OpenXR github page](https://github.com/GodotVR/godot_openxr/issues)! + +**The list of current known issues can be found [here](https://github.com/GodotVR/godot_openxr/issues?q=is%3Aopen+is%3Aissue+label%3Abug).** \ No newline at end of file diff --git a/collections/_article/godot-openxr-support.md b/collections/_article/godot-openxr-support.md new file mode 100644 index 0000000000..734cabc950 --- /dev/null +++ b/collections/_article/godot-openxr-support.md @@ -0,0 +1,50 @@ +--- +title: "Godot OpenXR support" +excerpt: "An update on the current work being rounded off adding OpenXR support to Godot 3 through a plugin and the planned work for Godot 4." +categories: ["progress-report"] +author: Bastiaan Olij +image: /storage/app/uploads/public/605/33d/fed/60533dfed520d231708447.jpg +date: 2021-03-18 11:57:39 +--- + +[OpenXR](https://www.khronos.org/openxr/) is a new open standard for interacting with XR hardware by the wonderful people at Khronos. This has been one of these rare cases where all the industry leaders have come together and come up with a standard that combines all the best practices of the different solutions available so far. + +With the announcement of the 0.9 specification roughly two years ago Microsoft showed off their runtime as well as [Collabora](https://www.collabora.com) with their open source Linux based OpenXR runtime called Monado. +Last year both Oculus and Valve introduced their runtimes and while still officially in beta they are fully functional at the time of writing this blog post. + +## Godot 3.3 OpenXR plugin + +It has flown under the radar somewhat but Godot was one of the first game engines to show off OpenXR support. Thanks to the wonderful work of Christoph Haag in porting the [OpenHMD](http://www.openhmd.net/) Godot plugin to OpenXR, Collabora was able to show off Godot running Calinou's port of the [Sponza demo](https://github.com/Calinou/godot-sponza) on Linux using a Vive headset back in early 2019. You can read their news article [here](https://www.collabora.com/news-and-blog/news-and-events/introducing-monado.html). + +Last year Bastiaan Olij started collaborating with Christoph Haag and helped add Windows support to the plugin, setting up automatic builds of the plugin, implemented a first version of the OpenXR action system with a focus on making it compatible with Godot's current controller approach, and added finger tracking support. + +Christoph is currently working on the still experimental Android support for OpenXR. + +The plugin has been tested to work well both within the Oculus and SteamXR ecosystems on Windows, and SteamXR and Monado on Linux. + +It is not yet available through the asset library but the latest build can be downloaded from [the releases page](https://github.com/GodotVR/godot_openxr/releases) on the [GodotVR GitHub repository](https://github.com/GodotVR). + +We've also made a start on documentation for the plugin [here](https://github.com/GodotVR/godot_openxr/wiki). It will tell you how to get going with the plugin. + +## Microsoft? Can we use Godot for the Hololens? + +Microsoft was one of the first to have a fully functioning OpenXR runtime, however it currently only supports DirectX. As Godot is an OpenGL based engine this has proven to be a stumbling block. + +Godot can work with DirectX and can run on UWP using the Angle OpenGL → DirectX library, so in theory this could be made to work. +However with Angle no longer being maintained by Microsoft and not having access to the required hardware, work on this has stalled. + +If anyone with experience in this area is willing to give it a go, please contact us! + +We don't know yet how thing will progress regarding Vulkan, whether Microsoft will introduce native Vulkan support or if any good Vulkan → DirectX library similar to MoltenVK for Vulkan → Metal will become available. + +## Godot 4 and OpenXR + +And that brings us to today. XR support on Godot 4 has stalled throughout 2020 due to the ongoing rewrite of the rendering backend, however with Bastiaan Olij being hired by the Godot organisation through a grant provided by [Facebook Reality Labs](https://godotengine.org/article/godot-engine-receiving-support-funded-facebook-reality-labs) specifically to focus on OpenXR support, the future is looking bright. + +February was used to round off a number of things in the Godot 3.2 OpenXR plugin and to work our ideas out further. This is a project that will take several months as we're not just bringing OpenXR support to Godot 4, we're also looking into specific optimisations in the render engine for mobile rendering and XR-specific needs, but we expect to be able to show some real progress soon! +The focus for March lies with getting the Vulkan renderer working on Android after which we'll start making changes to the rendering engine to support a better way of doing stereoscopic rendering then we had in Godot 3. + + +--- + +*The image is courtesy of* [**VRWorkout**](https://vrworkout.at/)*, a popular VR workout game made with Godot and available on SideQuest and Steam for free.* \ No newline at end of file diff --git a/collections/_article/godot-project-management-101.md b/collections/_article/godot-project-management-101.md new file mode 100644 index 0000000000..bb3f0c276e --- /dev/null +++ b/collections/_article/godot-project-management-101.md @@ -0,0 +1,122 @@ +--- +title: "Godot project management 101" +excerpt: "As we just reached our third goal on Patreon, we are now able to hire Rémi Verschelde (Akien) as full-time project manager and representative! In this article, he gives some insights on what brought him to Godot, how he helped organize the teamwork and became the de facto project manager, as well as plans for the future." +categories: ["news"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5ab/a37/9bc/5aba379bcde42258374818.jpg +date: 2018-03-27 12:24:07 +--- + +If you are eagerly watching our [Patreon page](https://www.patreon.com/godotengine) for news or following [Juan on Twitter](https://twitter.com/reduzio/status/978288010117529600), you might have seen that we just reached our third Patreon goal at a very generous USD 7,500 per month! + +After hiring our lead developer [Juan Linietsky](https://github.com/reduz) full-time in [September 2017](/article/patreon-first-goal-achieved), and our GDNative and GLES 2 developer [karroffel](https://github.com/karroffel) part-time in [December 2017](/article/please-help-us-reach-our-second-patreon-goal), we can now hire myself ([Rémi Verschelde](https://github.com/akien-mga)) full-time too as project manager, release manager, and representative! + +Given the good progress of our Patreon campaign, we actually anticipated this goal and I have been working full-time since early March (after quitting my previous job in February). Reaching the goal means that we'll be able to honor our payroll without having to eat into our limited pre-existing assets, which is more sustainable :) + +In this post I will try to highlight a bit what those three "positions" mean, to shed some light on the less glamorous but very needed management and public relations of a community-led FOSS project like Godot. For those interested, I'll start by a ~~quick~~ history of how I came to Godot and my involvement so far, which can give you a "real life" illustration of what community-led project management means. You can also skip directly to the "What now?" section if it's TL;DR for you ;) + +## From user to contributor and project manager + +I first heard of Godot in December 2014, [when version 1.0 was released](/article/godot-engine-reaches-1-0) (note that author information on those old blog posts is incorrect, I was not posting articles at that time :)). I was (and still am) quite fond of Free Software, including libre games, and a free and open source engine that runs natively on Linux was very appealing to me. My first interest was actually to package Godot for my Linux distribution [Mageia](https://www.mageia.org), which was the first one with an official Godot package. Like Godot, it's a community-led not-for-profit free and open source project, so I could eventually reuse my Mageia experience to help improve Godot's development. + +I read some of the documentation and tried demos, but only started learning and using the engine for real mid 2015 with [version 1.1](/article/godot-1-1-out). Since I was familiar with open source projects, I quickly found my way to the GitHub repository to report a few bugs and enhancement requests. + +I saw that there was a great momentum and that Juan was a very friendly and caring project maintainer, but that there were some things hindering the project's full potential: + +1. The issues repository was a mess. Most issues lacked the information that could actually be of use to developers (detailed bug description, steps to reproduce, affected version and platform, etc.), and a big part of the issues were actually fixed already in released versions of Godot, but nobody had taken care to close them. Juan (and [Ariel](https://github.com/punto-) too to a lesser extent) was the only one able to manage the issue tracker, and did not have time nor bug triage experience to do it efficiently. + +2. Similar story for pull requests (PRs). Most PRs had inconsistent code quality and style, and a relatively messy git history (e.g. 3 or 4 merge commits in the same PR for a simple change in one file). Here again Juan was the only one "in charge" of reviewing PRs, and that showed. Worse for the momentum of the project: Juan likes to stay focused when developing features, so he would not check PRs often. He would usually check all PRs at the same time once a month, and merge most of them after a quick glance, then do fixes himself for what was problematic in some of the merged PRs. This had two negative effects: + + * No real code review was done, and good features with not-so-good code were merged, slightly increasing the technical debt. + * Most contributors had to wait for weeks if not months to get feedback on their PRs. Since most of those were first-time contributors, they would eventually stop caring about the project and move to something else. + +3. It was almost impossible to contribute to the documentation. We were using the GitHub wiki feature at that time, which meant that only users with write access to the git repo could modify documentation. At that time, that meant only Juan and Ariel, since they were understably not willing to give full permissions on the repo to new contributors. + +4. Release cycles for minor versions were long (6 months from 1.0 to 1.1, 8 months from 1.1 to 2.0), and in the meantime some users were stuck on an outdated stable versions while others were putting up with the occasional post-mass-merge instability in the *master* branch. + +Back then I did not formalize those issues as clearly, but I saw that stuff needed to be done and that I had experience with it thanks to my involvement in Mageia as a packager, QA tester and bug triager. As a jack of all trades and master of none, I started working on a bit of everything that seemed necessary for the project to continue growing and be successful. + +### Bugsquad + +So I started with the most pressing issue: developers (be it Juan or any other contributor) can't work efficiently if they don't know what are the bugs users are experiencing in the engine, and how to reproduce them. I started by going through issues, asking reporters for more details or to check if their issue was still valid in Godot 1.1 or the master branch... it was tedious work but helped us close some obsolete issues and prioritize some valid ones. I still wasn't able to press the "Close" button on issues myself though, due to GitHub's restriction that only people with write access to the repo (i.e. able to push commits live without making PRs) could triage issues, though I was still dependent on the issue reporter or Juan closing the fixed issues. + +Eventually I harassed Juan so much that he agreed to give me write access to the repo, as well as to a couple other trustworthy contributors, to organize the "Bugsquad" or bug triage team. Its role was (and still is) to assign labels to issues (bug report, enhancement request, what platform does it affect, what part of the engine is it about, etc.) and pull requests, and ensure that fixed or invalid issues were actually closed and that open ones were descriptive enough to be useful. It took us several weeks of work to go through the backlog of 2,000 issues, but we could close about half of them and give more visibility to the still valid ones (leading to a much better user experience in Godot 2.0, since contributors could find and fix usability quirks much faster). I did a big part of that work initially, and little by little I encouraged more experienced Godot users to join the Bugsquad and help spread the workload. + +### Merging PRs + +In parallel, I started bugging Juan regularly about pull requests. It was hard for me to review them with very little experience with the engine's internals, but some were simple enough even for me to understand: typo fixes, documentation updates, compilation fixes (there was no CI and some platforms broke regularly), or usability improvements in the editor. It made no sense for such changes to wait in the limbo for the next "big merge" a month later, so I sent Juan links to PRs to review and merge in priority on IRC. + +Eventually, since I had full write access to the repo because of the Bugsquad's work, Juan told me that I could merge such PRs myself if I was confident enough. I was a bit impressed to have so much responsibility while being a quite average developer (I'm energy engineer initially, not engine programmer :)), and afraid to do mistakes. But I went ahead and merged some stuff, at first very conservatively, and later on a bit boldly. The first reverts when I merged something that I shouldn't have arrived quickly, but I got better at reviewing PRs and got more familiar with the engine itself. + +And what we saw happen was well worth the effort: in the months following the initial big Bugsquad triage of the issues backlog and the faster PR reviews, we saw a lot of new contributors come to the engine, and many existing ones staying and gradually becoming our first "core contributors", doing several PRs each month. In one month we doubled the number of monthly PRs, and it kept on increasing. Existing and new contributors were more motivated when seeing that contributions were valued, reviewed and merged (or refused, if need be) quickly. + +Eventually I spent so much of my (free) time reviewing and merging PRs that it was not sustainable in the long run, so with Juan we created a "PR mergers" team and invited some core contributors to it, so that they could review and merge PRs themselves (they could already review them without merge permissions, but it's more effective to get contributors to do work for free when they have a responsibility ;)). + +### Migrating the documentation to ReadTheDocs + +As mentioned, Godot's documentation was initially in a GitHub wiki, and could only be edited by developers with write access (so only Juan and Ariel initially, later on the Bugsquad too). It was a big issue as the docs were far from perfect, and many users wanted to contribute. + +Thanks to [Theo Hallenius](https://github.com/TheoXD), we migrated our Wordpress website, phpBB forum and GitHub wiki to a common [OpenProject](https://www.openproject.org) instance. Theo did a lot of work to convert the GitHub wiki (in Markdown) to the Textile markup format used by OpenProject, and it was great: we finally had a wiki that any logged user could edit, and we even had localized versions of the wiki (far from completion, but there were starts of Spanish, Chinese, French wiki, etc.). Sadly we quickly started to have big performance issues with OpenProject, making it often unreachable or very slow. After trying several things to fix those issues, we eventually decided to migrate everything again to a new modular setup (the current one): the website and blog on OctoberCMS, the forum outsourced to the nascent [GodotDevelopers](https://godotdevelopers.org/forum) community, a new Q&A to replace it in the main website and be more focused on a StackOverflow-like platform, and the docs moved to a git repository using [Sphinx](http://sphinx-doc.org/) and [ReadTheDocs](https://readthedocs.org). + +Understandably, Theo did not wish to work on yet another migration after we decided to abandon the work he had just did, so others had to take over. I naturally took on the "manager" hat and helped coordinate the work of our contributors (especially [Alket Rexhepi](https://github.com/alketii)) on the website's backend, design, etc. + +And on my end I looked into how to migrate the OpenProject wiki to something better. I was no happy with the wiki system as it typically lets anyone make edits, and you have to review edits afterwards and correct issues, if any. It seemed to me that using a GitHub repository for the documentation, with the same PR workflow as for the engine code, would be the most efficient. Sure, learning how to use git and our PR workflow would be a hindrance to some technical writers, but we found that the pros outweighed the cons. + +I settled on the Sphinx doc builder, which generates static HTML pages based on source files in the reStructured Text markup language (yet another conversion needed, [Julian Murgia](https://github.com/StraToN) and I became pretty good at regular expressions!), and the ReadTheDocs platforms, which provided hosting, automated builds on new commits, and a great looking theme. This is still the system that we're using today for the [official documentation](http://docs.godotengine.org/) and we are pretty happy about it! + +For the first year and a half or so Julian and I did our best with limited time to manage the [docs repository](https://github.com/godotengine/godot-docs). Then a year ago or so, we encouraged professional tutorial makers like Nathan Lovato ([GDquest](https://github.com/NathanLovato)) and Chris Bradfield ([KidsCanCode](https://github.com/KidsCanCode)) to help us, and they eventually completely took over, making our 3.0 documentation the most complete and well-written so far! And with "recent" contributors like [Max Hilbrunner](github.com/mhilbrunner), they are now reproducing the workflow that I outlined above, with a better issue triage and reviews of pull requests, so that the godot-docs repository is becoming a hive full of buzzing documentation bees working everyday to improve your learning experience! + +### Making stable and develpoment releases + +The last big issue I had noticed was the long release cycles and lack of bugfix/maintenance releases in the stable branches. Coming from the Free Software ecosystem, I knew the value of the *release early, release often* saying, and wanted more frequent releases for Godot. + +At the same time, we started running out of credits on the build server that Ariel was using to make the official binaries, so we needed to look into (cheap or free) alternatives. + +With the help of various contributors, we setup a full buildsystem (ab)using [Travis CI](https://travis-ci.org) to build Godot binaries for all platforms, and then upload them to a [GitHub repository](https://github.com/GodotBuilder/godot-builds) (since then we replaced the cross-compiled MinGW Windows builds on Travis by native Visual Studio builds on AppVeyor, but it's still the same idea). Though CI services are not designed for this, it allowed us to get binaries for a wide variety of platforms, including macOS and iOS without needing to buy/rent a macOS server ourselves. + +Using this new system, I could prepare official builds of Godot more often (still not in a nightly fashion, as the whole setup would still take 5 to 10 hours to build everything, and I didn't want to DoS Travis' infrastructure with Godot builds). We could publish frequent beta builds of Godot 2.0 to get more testing before the final release in [February 2017](/article/godot-engine-reaches-2-0-stable), which turned out pretty good! + +Once 2.0 was out, I decided to keep maintaining a stable 2.0 branch with bugfix releases, while development was ongoing for Godot 2.1. So I branched off at the 2.0 release commit, and started cherry-picking bugfixes and usability improvements to this stable 2.0 branch. We [released 2.0.1](/article/updates-on-the-release-cycle-and-godot-2-0-1) a couple of weeks after 2.0, and so on and so forth up to 2.0.4.1. And we did the same for the 2.1 branch. + +Now with [Godot 3.0 released in January 2018](/article/godot-3-0-released) and the huge community growth that we experienced over the last year, we decided that stable branches needed more guarantee of forward compatibility (you should be able to run your 3.0.1 project in Godot 3.0.4 for example). [Hein-Pieter van Braam](https://github.com/hpvb) proposed to offload me of this responsibility and to be the official maintainer of the 3.0 branch, which I gladly accepted. For now I'm still handling the buildsystem and helping review what should be backported to the stable branch, but he's taking on more and more of the work so that I can focus on the master branch. + + +## What now? + +The above was meant to be a *quick* (haha) overview of how I came to Godot and what I helped setup for the project to be as successful and fast-growing as possible. It turned out to be a very detailed history (I hope not too boring, but as you can see I like talking of things I'm passionate about :)), but the conclusion of each part is: I set up and maintained a ton of stuff, and now I'm offloading more and more of this ever-increasing workload to new contributors. + +So what's next? What am I going to work on especially now that thanks to our generous patrons, I can work on Godot full-time? + +### Keep doing it + +Well the first part of my "new job" is not really revolutionary: I'll keep doing what I have been doing for 2.5 years. Even though I'm offloading more and more of those tasks to other contributors, the community is growing at a tremendous pace, and at each major or minor release that we have the workload basically doubles. + +So I'll continue working on sharing and even giving over more of my responsibilities to other contributors, but as I just wrote it, that's work too. And we still need someone to coordinate the work of the different teams. + +Moreover, I'm now working full-time on Godot as my paid job, but I was already basically working 30+ hours a week for free previously next to my normal full-time paid job (and partly overworking myself), so I don't have so much more time right now if I want to keep some more of my newly found free time for different healthy activities :) + +### Be Godot's representative for the industry + +Thankfully I haven't detailed it in my long history of all the Godot things I've been doing in the past, but I have also taken the role of communications manager (writing blog posts, managing social media accounts and Godot email addresses, etc.) and events organiser (FOSDEM, GodotCon, etc.), and I'll continue doing that. + +But now I have actual time that I can allocate to create and nurture Godot's relationships with the gamedev industry and the educational world, as the project's representative. As Juan mentioned in his [GDC 2018 review](/article/godot-doing-well-gdc-2018), with events such as GDC he has to spend a lot of time doing communication and relations work instead of writing code and (more importantly) help contributors write code. At the same time he lives in Argentina and many industry events take place in Europe, where I live. + +So the idea is that I should take over part of those tasks, and push them further: I'll give talks and workshops at universities, meet companies to talk to them about Godot (and sponsorship!), participate in industry events, etc. + +This also includes all kinds of administrative tasks needed for the project, such as applying for grants or programmes like the Google Summer of Code (GSoC), and then following up on them. For example I've spent most of the past week answering questions from prospective GSoC students and reviewing their draft applications, as well as encouraging fellow contributors to volunteer as mentors for the GSoC programme. + +Just like all the other things I've been working on in Godot, I'll also gradually find ways to offload more of this work to the community: that might include helping setup local communities which could organize events of their own in the town/region, collect and improve presentation and teaching material for users and teachers to use in their talks or curricula, etc. + +What it will all be *exactly* is still to be determined, but we definitely agree with Juan and other core contributors that Godot needs public figures who can do the link between our hardly-known yet awesome bundle of technology and the real world, with its needs and expectations. This should eventually help us gain more adoption, more contributions, more funding and more awesome features and – that part is yours – games! + +## Next goals + +With the impressive USD 7,500 milestone reached, we can now pay salaries for Juan and I (USD 3,000 each) and karroffel (who works part-time and as an intern, so she's exploited for USD 1,050 from us + USD 400 from a generous thirdparty interested in her work). That's actually slightly less than we needed for this payroll as we also give 10% of our donations to our fiscal and legal sponsor [Software Freedom Conservancy](https://sfconservancy.org), so strictly speaking we need over USD 7,800 per month. But 7,500 was a rounder symbolic value :) + +On top of that, we'd like to have some cash flow to pay for travel expenses, as when Juan goes to Europe for GodotCon or to the US for GDC 2018, plane tickets are pretty expensive. As the project representative, I'll also be travelling a lot in Europe to meet companies, universities and take part in industry events. In first approximation we're setting a goal at USD 9,000 that should reflect the monthly expenses we expect to have in the near future (if you've followed, that USD 8,100 for Godot, so ca. USD 1000 for variable expenses after paying salaries). + +Once we've secured that, we'll think about growing the team of paid contributors again, as we have quite a few very talented contributors who would welcome a part-time job to work on the engine. + +Another, simpler alternative to get more paid developer time on the engine is for thirdparty companies to hire Godot contributors themselves to work on what they need and contribute it upstream. That's what Pedro J. Estébanez [is doing with AdPotNet](/article/let-people-touch-godot) for example, and we want to encourage more companies to do the same, as it's much more flexible than going through Conservancy and donation-based income (and should also be more lucrative for contributors hired for such contracts! ;)). + +I hope this writeup helped shed some light on how the Godot project is managed, including how we handle donations and what we use them for. If you have any question, you can ping me on IRC or Discord (Akien). \ No newline at end of file diff --git a/collections/_article/godot-ragdoll-system.md b/collections/_article/godot-ragdoll-system.md new file mode 100644 index 0000000000..2befef128f --- /dev/null +++ b/collections/_article/godot-ragdoll-system.md @@ -0,0 +1,99 @@ +--- +title: "Godot's ragdoll system" +excerpt: "Godot 3.1 is getting many improvements on the physics side, and one of those is the new ragdoll system. Physics maintainer Andrea Catania presents the work he did on this topic and how to get started with physical bones and ragdoll simulation." +categories: ["progress-report"] +author: Andrea Catania +image: /storage/app/uploads/public/5af/c2e/449/5afc2e44937d1306025773.png +date: 2018-05-16 13:18:30 +--- + +Godot is getting more and more interesting features in this period, and one aspect on which we are focusing on is the Skeleton node. + +We are working on implementing some features like Inverse Kinematics, Ragdoll, a better animation player, and a state machine player. All these things will allow the developers and artists to apply some animations to their characters easily and at the same time with an awesome result. + +I'm [Andrea Catania](https://github.com/AndreaCatania), and in this article I will explain how to use the new Ragdoll feature available in Godot (in the *master* branch coming in Godot 3.1). But I'll start with a couple lines to introduce myself. I'm the contributor who integrated the [Bullet Physics](http://bulletphysics.org/wordpress/) engine in Godot 3.0, which was my first Pull Request about a year ago. I'm now taking care of most physics things and animation (like ragdoll, IK, SoftBody, etc.). I'm a computer graphics and physics passionate, and always looking to learn and discover new things. + +Now let's start! + +## How it works + +To show you how to use it, I will apply it to the Platformer3D demo that can be downloaded [on GitHub](https://github.com/godotengine/godot-demo-projects/tree/master/3d/platformer) or on the [Asset Library](https://godotengine.org/asset-library/asset/125). + +#### Create physical bones + +The first thing to do is to select the skeleton node (in the player scene of *Robi* the robot). You will notice that a skeleton button appears on the top bar menu: + + + +Click it and select the **Create physical skeleton** option. The engine will automatically generate physical bones (with their own shape) for each bone of the skeleton. + + + +#### Clean up the skeleton + +In the picture above, you can see that there are unnecessary physical bones like the MASTER bone, so the first thing to do is to clean up our skeleton by removing these physical bones. + +The rule is that you should remove all physical bones that are too small to make a difference in the simulation and all utility bones (like the MASTER bone in this case). + +> For example, if we take a humanoid skeleton where the hand is comprised of many bones, it's really useless and wasteful to maintain all bones of the hand. One important thing to do in this case is to remove all physical bones and replace them by one or two bones to simulate the hand. + +To clean up our Robi I chose to remove these physical bones: MASTER, waist, neck, headtracker. +This step is not mandatory but it is recommend to clean up the generated skeleton, so that you end up with an easy to maintain and optimized skeleton structure. + +#### Collision shape adjustment + +After cleaning it up you will have to adjust the collision shape and/or the size of physical bones in order to match the part of body that each bone should simulate. + + + +#### Joints adjustment + +After the collision shapes adjustment your ragdoll is ready to be used, but before doing it I like to change the joint between each bone. + +The joint assigned by default is **Pin Joint** that doesn't has any constraint. To change it you should select the physical bone then change the type of constraint in the Joint section. It's possible to change the orientation of constraint and limits. + + + +Now Robi's head will move like a real head! + +My final result is this: + + + +#### Start and stop the simulation + +Now it's really simple to start the simulation by attaching a GDScript and writing down this code: + +``` +func _ready(): + physical_bones_start_simulation() +``` + +To stop it you can call the function `physical_bones_stop_simulation()`. + + + +But what if I want to start the simulation for just a few parts of the body? Yes, it's simple enough to do by changing only one line of code: :P + +``` +func _ready(): + physical_bones_start_simulation(["r-arm", "l-arm"]) +``` + +With the code above, we are passing to the engine the names of bones for which we would like to simulate physics, and this is the result: + + + +## Collision Layer and Mask + +Last but not least you have to properly set layer and mask in a way that doesn't collide with kinematic capsule but collide with ground: + + + + + +## What's next? + +The next thing that I will implement is the active ragdolls that will allow us to influence the physical bone position. This mean that the body will tend to maintain a defined position while ragdoll is active. + +That's it for now, enjoy ragdolling! \ No newline at end of file diff --git a/collections/_article/godot-reaches-2-1-stable.md b/collections/_article/godot-reaches-2-1-stable.md new file mode 100644 index 0000000000..cdfb71adb0 --- /dev/null +++ b/collections/_article/godot-reaches-2-1-stable.md @@ -0,0 +1,157 @@ +--- +title: "Godot reaches 2.1 stable!" +excerpt: "After almost six months of hard work, we are proudly presenting you the marvellous Godot Engine 2.1. Just like 2.0, this version focuses almost exclusively on further improving usability and the editor interface." +categories: ["release"] +author: Juan Linietsky +image: /storage/app/uploads/public/57a/886/5d5/57a8865d5dc44195460713.png +date: 2016-08-09 19:38:43 +--- + +## Godot 2.1 stable is here! + +After almost six months of hard work, we are proudly presenting you [the marvellous Godot Engine 2.1](/download). [Just like 2.0](/article/godot-engine-reaches-2-0-stable), this version focuses almost exclusively on further improving usability and the editor interface. + +This release marks the conclusion of a series focusing on usability improvements. We have listened to and worked with our awesome community to make Godot one of the easiest game development environments to use. Our goal is and will always be to aim for the top in the *ease of use* vs *power* ratio. + +**[Download it now](/download)** while you read on! + +There are countless new features in this version (see the full changelog, [chronological](http://download.tuxfamily.org/godotengine/2.1/Godot_v2.1-stable_changelog_chrono.txt) or [listed by contributor](http://download.tuxfamily.org/godotengine/2.1/Godot_v2.1-stable_changelog_authors.txt)). The most important ones are: + +### New asset sharing platform + +Godot 2.1 comes with our new asset sharing platform, the Asset Library. It's still new and far from final, but it will continue evolving to satisfy everyone's needs. The idea is that users can post assets, scripts, addons, etc. online (for example hosted on GitHub or GitLab) while offering an easy user interface to download and install them. Your feedback to make the asset library awesome is vital! + + + +As of the 2.1 release, the asset library features only a handful of assets, which have been used to test the upcoming [open source web frontend](https://github.com/godotengine/asset-library) for submitting and managing assets. Thanks to the development work done by [Alket Rexhepi](https://github.com/alketii) and [Bojidar Marinov](https://github.com/bojidar-bg), this frontend will soon reach the alpha status and be announced officially, so that all community members can start submitting assets to the library. + +### New plugin API + +Together with the Asset Library, we have introduced an EditorPlugin API for Godot. Plugins can add a lot of different functionalities to the editor, and provide new node types and features to games. As this is our first attempt to a plugin API, we imagine that many useful functionalities might still be missing so, again, we are counting on your feedback to make this API as great as it can be. + + + +### Dynamic font support + +Godot is used all around the world and, while it always supported Unicode, its reliance on font textures made it pretty difficult to support some languages (especially Asian). This new version allows you to drop any TTF or OTF file in the project and use it directly in your games, at any size. + +Fallback fonts are also supported, so it is possible to work around the 64k character limit and use true multi-language text. + + + +### Fully internationalized editor UI + +Together with dynamic fonts, we are now able to offer you Godot in a large amount of languages. Many users from around the world who are not at ease with English can do their first steps in Godot in a way more familiar to them. + + + +As of the 2.1 release, the community has [contributed translations on our Weblate platform](https://hosted.weblate.org/projects/godot-engine/godot/) for an important number of languages. Italian, Korean, Brazilian Portuguese, Russian and Spanish are 100% complete; other languages like Chinese (Simplified), French, German and Polish should also offer a good level of translation already. + +### Editor visual customization + +Together with the above, we also added support to change the font styles and sizes, as well as creating custom editor themes. User-made themes should soon land on the Asset Library too for everyone to use as they wish. + + + +### Customizable keybindings + +One of the most requested features is finally here! Keybindings in Godot can now be fully customized in the editor settings! This also includes a number of features that previously had no default binding, and that you can now bind to a key if you use them often. + + + +### Live script reloading + +Tired of having to reload your game for each small little code change or fix? Godot now supports live script reloading! Simply save your script and it will be updated in the running game. + +If you are running your game on an external device (*e.g.* Android), and using "Deploy with Remote Debug", live script reloading will magically happen in there too. + +We have also cleaned up the remote menu for this version to make these options easier to understand and use. + + + +As a plus, tool scripts running in the editor will properly reload if you re-save them too, making it easier to develop them. + +### Profiler & frame profiler + +It is now possible to measure the time taken in each function call (both inclusive and self), while doing profiling runs (profiling can be turned on and off at any time). In addition, Godot will remember the time it spent in the most significant functions in the last 500 or more frames, which you can browse easily by scrubbing a pretty function plot. + +As with everything, if you are running Godot on an external device (Android, iOS) with remote debug enabled, you can profile the performance of that device from the editor in your PC. + + + +### Remote scene inspector + +The approach chosen by Godot for live editing makes it really easy to create content on the fly, have it replicated in the running game, and keep your changes when the game is done running. The disadvantage is that, unlike other engines, it's more difficult to see the values of scenes and nodes in the running game. + +As of 2.1 this is no longer true, as the debugger has a new field "Remote Inspector", which allows watching the scene tree of the executed game in real-time, as well as the properties of each node and resource. Editing such properties is possible too, but changes won't be saved (use regular live editing for this). + + + +### HiDPI/Retina support & hi-res icon theme + +Godot now supports HiDPI and Retina. For the editor, this is done via auto-detection of the monitor resolution (it no longer looks tiny on Linux and Windows with HiDPI). For the running game, you can toggle a flag in the project settings (make sure to enable it in OSX if you want your project to display in hi-res). + +There is also a beautiful new flat icon theme which supports HiDPI, courtesy of [Daniel Ramirez](https://github.com/djrm). + + + +### Drag & drop support + +The world has changed and some user interface conventions have evolved since Godot was made. New users used to find Godot a little rough due to not being able to drag around information. + +From this new version onwards, drag & drop is fully supported in the editor. You can drag resources from the inspector or filesystem, nodes to rearrange and reparent them, and in general all kinds of lists and previews. If you believe that some editor sections could further benefit from this functionality, let us know! + + + +### Contextual menus + +In the same vein as drag & drop support, Godot now supports contextual menus in many relevant places, such as the filesystem dock, the scene tree, etc. Right-clicking will bring up a menu in the expected places. Here again, feel free to suggest other places where contextual menus could be beneficial to the overall usability. + + + +### Script editor usability improvements + +The script editor has seen many usability improvements, including a find/replace bar, incremental search, better syntax highlighting, smart-matching in code completion and many other goodies thanks to the awesome work of [Paul Batty](https://github.com/Paulb23), [George Marques](https://github.com/vnen) and [Ignacio Etcheverry](https://github.com/neikeq). + + + +### Improved asset pipeline + +The way assets are handled in Godot changed a bit. We now enforce auto-import of assets that changed externally, and auto reload of assets that changed on disk. Dropping files from the OS native filesystem browser into Godot will also pop-up the corresponding import dialog into the selected folder. + +Importing 3D scenes also suffered some changes, as scenes will no longer be merged by default. Trying to keep track of what changed and how to merge it proved to be a lot of work, so instead, we now encourage users to try the scene inheritance feature to do local modifications to imported scenes. (Just import the scene, and inherit it into another scene to make the changes). It is now also possible to select the root base node type when importing 3D scenes. + + + +### Improved resource previews and thumbnailer + +As part of improving usability, we have made many enhancements to the thumbnailer. More resource types are supported and thumbnailing of internal scene resources is also supported, allowing previews of materials, meshes, etc. + +Added to that, we added a small resource previewer at the bottom of the inspector, which works for many resource types. + + + + +### New AnimatedSprite features + +While using an AnimationPlayer to switch frames is a very powerful approach, we always felt AnimatedSprite could be a little more accessible to new users. To do this, we added multiple animation support to it, and the ability of simple auto-playing of animations at a given speed without the need of using an AnimationPlayer. + +Finally, we reworked the UI to make it more accessible, with full drag & drop support. + + + +## Future + +This has been a fun and exciting release, and we feel Godot is finally where we want it to be in terms of usability. It has been more than a year since 1.1 was released and not focusing on new core engine features for so long was difficult, yet we feel it was worthwhile as Godot is now much more accessible than it used to be. + +From now on, and for at least a few releases, we will focus on making Godot even more fabulous. Our next release is already in the works and will be 2.2 (which we hope to deliver in 2/3 months). It will include a new visual scripting language, support for Mono (C#), high level multiplayer networking and a more advanced audio engine. It should also feature many improvements to 2.1 features such as the Asset Library or plugin API, based on your feedback over the coming months. + +Meanwhile, work on Godot 3.0 is starting already (expected in 6/7 months from now), and will include a new reworked, modern renderer with support for Physically Based Shading, improved shader language, VR, and many other nice things, as well as a greatly improved HTML5 export platform with WebAssembly support. + +Our goal with 3.0 will be to have a game engine that can output really, really beautiful 3D visuals involving a lot less hassle than existing solutions. We know how difficult it is for artists and even programmers to make things look good with existing game engines, so our approach will be to give you every tool you need for your game to look great out of the box using built-in Godot features. + +## Spread the word! + +As always, we ask you from the bottom of our hearts to spread the word about Godot. We know how good this little engine we are making together (developers and community) is, but we are still little known in the game development world. With no marketing budget and 100% voluntary contributors, we need every member of the community to partake in the effort and spread the love of Godot by word of mouth, blog posts, press articles, game jams and events, published games, etc. + +Please make as much noise as you can so that more developers know about us and give a try to our professional-grade open source game engine! :) \ No newline at end of file diff --git a/collections/_article/godot-rmll-2015-france.md b/collections/_article/godot-rmll-2015-france.md new file mode 100644 index 0000000000..d9116dcf7a --- /dev/null +++ b/collections/_article/godot-rmll-2015-france.md @@ -0,0 +1,32 @@ +--- +title: "Godot at RMLL 2015, France" +excerpt: "Juan Linietsky, one of the main developers of Godot Engine will be giving a talk and a workshop about Godot Engine at RMLL2015." +categories: ["events"] +author: Juan Linietsky +image: /storage/app/uploads/public/56c/317/2a0/56c3172a03b59083821998.png +date: 2015-06-11 00:00:00 +--- + +## Godot at RMLL 2015 + +Juan Linietsky, one of the main developers of Godot Engine will be giving a talk and a workshop about Godot Engine at RMLL 2015. As most of them reside in South America, this is a great opportunity for Europeans to learn about Godot, meet the developers and have the chance to go out for beers! + +RMLL takes place in Beauvais, a city a little north of Paris, from July 4 to July 10. + +The schedule will be: + +* **Tuesday 7 July, 15:20**: Introduction to Godot Engine (talk) +*Edit:* The video recording of the talk can be [viewed online](http://video.rmll.info/videos/introduction-au-moteur-godot/). + +* The time and date of the workshop is TBA but should be the same or the next day. +More information at the [RMLL website](https://2015.rmll.info). + +Thanks enormously to the organization of RMLL for this invitation! + +## Godot in Paris + +Juan will be having meetings in Paris the week from the 10 to the 17, so if you want to schedule a meeting with him (or just want to go out for beers), please contact him beforehand! + +## Spread the love! + +If you have contact or work in the organization of technology, video game development or libre software events, and would like to bring one of the main Godot developers, also contact us. We are also working hard so everyone willing to give a talk in their local community can have access to the materials we use in our talks and workshops (please help us translate them to your native language!). \ No newline at end of file diff --git a/collections/_article/godot-rmll-lsm-2018-strasbourg-july-7-12.md b/collections/_article/godot-rmll-lsm-2018-strasbourg-july-7-12.md new file mode 100644 index 0000000000..f84c01c807 --- /dev/null +++ b/collections/_article/godot-rmll-lsm-2018-strasbourg-july-7-12.md @@ -0,0 +1,33 @@ +--- +title: "Godot at the RMLL / LSM 2018 in Strasbourg, July 7-12" +excerpt: "Godot will be at the Libre Software Meeting 2018 (also known as RMLL – Rencontres Mondiales du Logiciel Libre) in Strasbourg, France from Saturday 7 July to Thursday 12 July. We will give a 1-hour talk, a 3-hour workshop and will have a Godot booth for the whole duration of the event." +categories: ["events"] +author: Rémi Verschelde +image: /storage/app/uploads/public/5b3/392/f85/5b3392f852017497603465.png +date: 2018-06-27 13:37:02 +--- + +Godot will be at the [Libre Software Meeting 2018](https://2018.rmll.info/en) (also known as RMLL – *Rencontres Mondiales du Logiciel Libre*) in Strasbourg, France from **Saturday 7 July** to **Thursday 12 July**. We will give a 1-hour talk, a 3-hour game development workshop, and there will be a Godot stand with core developers to welcome you for the whole duration of the event. + +[LSM](https://2018.rmll.info/en) is a yearly community event in France focused on Free/Libre and Open Source Software, and we're looking forward to representing Godot there this year. At least three core developers will be there (Julian Murgia ([StraToN](https://github.com/StraToN)), Gilles Roudière ([Groud](https://github.com/Groud)), and myself ([Akien](https://github.com/akien-mga))), and we hope that some more as well as many Godot users will join us in Strasbourg. The location should make it relatively accessible for people from neighbouring regions of France, Germany, Switzerland, Belgium and Luxembourg. + +## Godot-related activities + +We have three Godot-related offers for visitors of the LSM. Note that they are all located in different buildings of the LSM venue, see the [venue map](https://2018.rmll.info/en/info/map) as well as each activity's page for details. + +- **Godot stand** in the [Libre Village](https://2018.rmll.info/en/program/calendar/list#saturday-village) during the whole event. We'll be there showcasing Godot, games made with it, and selling the awesome T-shirts designed by Daniel Ramirez ([djrm](https://github.com/djrm)) :) If you're coming to LSM, please come to our stand and say hi. You'll also be welcome to give us a hand manning the booth and talking about Godot to visitors :) + * *Location:* + - **Update:** Saturday 7 July: [Shadok](https://www.shadok.strasbourg.eu/) (25 Presqu'île André Malraux, 67100, Strasbourg) + - Sunday 8 July and following days: [Central Campus of the University of Strasbourg](https://2018.rmll.info/en/info/access), ESCARPE building (11, rue du Maréchal Juin, 67000 Strasbourg). +- [1-hour presentation of Godot](https://2018.rmll.info/en/program/calendar/list#saturday-track16-0) on **Saturday 7 July at 11:00 CEST** with Julian and Gilles. + * *Location:* [Central Campus of the University of Strasbourg](https://2018.rmll.info/en/info/access), ESCARPE building, amphitheater 29 (11, rue du Maréchal Juin, 67000 Strasbourg). +- [3-hour workshop to learn how to make games with Godot](https://2018.rmll.info/en/program/calendar/list#saturday-track16-2) on **Saturday 7 July at 14:30 CEST** with Julian, Gilles and myself. + * *Location:* [Central Campus of the University of Strasbourg](https://2018.rmll.info/en/info/access), PLATANE building, amphitheater 12 (allée René Capitant, 67000 Strasbourg). + +**[Indicative poll](https://framadate.org/godot-rmll-2018):** It's not mandatory, but to give us an idea of who to expect, you can [add yourself to this poll](https://framadate.org/godot-rmll-2018). We may plan a Godot dinner and/or a real-life meeting if we have many community members around, so you can send me your contact details (email in the poll description) if you want to be in the loop. + +## Other LSM / RMLL activities + +Check the event's [presentation](https://2018.rmll.info/en/program/presentation), calendar of activities [as a table](https://2018.rmll.info/en/program/calendar/table) and [as a list](https://2018.rmll.info/en/program/calendar/list). + +We're looking forward to seeing many new and old members of the Godot community in Strasbourg :) \ No newline at end of file diff --git a/collections/_article/godot-showcase-2dynamic-games-lumencraft.md b/collections/_article/godot-showcase-2dynamic-games-lumencraft.md new file mode 100644 index 0000000000..181c9034f1 --- /dev/null +++ b/collections/_article/godot-showcase-2dynamic-games-lumencraft.md @@ -0,0 +1,83 @@ +--- +title: "Godot Showcase - Lumencraft developer talks about his experience" +excerpt: "We interviewed Leszek Nowak from 2Dynamic Games about their game Lumencraft, which is made with Godot." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/625/6ff/331/6256ff331f974859299358.jpg +date: 2022-04-13 15:00:00 +--- + +Welcome to another Godot showcase interview! This time, we interviewed Leszek Nowak from 2DynamicGames about their latest release Lumencraft. + +___ + +### Introduce yourself (or your studio) in a few sentences. + +My name is [Leszek Nowak](https://twitter.com/JohnMeadow3) and I’m a part of independent studio 2Dynamic Games located in Kraków, Poland. We are a small team working on our first team project, Lumencraft, which is released as I'm writing this. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Lumencraft is a top-down shooter with base-building elements where you're a lonely little digger sent into bug infested underground caves. +The game is made in Godot Engine 3, with many custom-made technologies that enable a fully destructible environment, fluid simulation and dynamic lighting. + +The game releases into Early Access on April 13th, 2022 for Windows, Linux, Steam Deck, and in the near future macOS. +You can find it on [Steam](https://store.steampowered.com/app/1713810/Lumencraft/) and [GOG](https://www.gog.com/en/game/lumencraft). + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +I have years of random experience in development with my first games made way back for Commodore 64. I used the most known game engines there were, and some of my obscure games were made in Pascal, and even Matlab. + +Since the path of a game developer is rarely straightforward, I ended up as an academic at the university doing PhD in skin cancer research, and as a part of not doing the PhD I started writing my own game engine. Luckily my students introduced me to Godot Engine and since 2014 it is my favorite tool. As of now, I have 40+ random free and open source games made in Godot, some can be found on [itch.io](https://johnmeadow.itch.io/) and [Global Game Jam](https://globalgamejam.org/users/john-meadow). You might find something that resembles Lumencraft in there. + +As it happens, the 2Dynamic core team had to deal with me as their teacher at some point in their university life, with me preaching Godot at any opportunity. +One of the successful conversions to Godot was [Paweł Mogiła](https://twitter.com/PawelMogila) (szamq), the architect of Lumencraft. He published [Grimind](https://store.steampowered.com/app/265380/Grimind/) in his custom SDL-based engine and [Clinically Dead](https://store.steampowered.com/app/927840/Clinically_Dead/) using [Urho3D](https://urho3d.io/). + +Luckily, one of the core contributors of Godot Engine happened to end up in the same University and was persuaded to join the team. [Tomasz Chabora](https://twitter.com/KoBeWi_) (KoBeWi) is making all the things work properly. + +### Why did you choose Godot for your project? + +It comes down to Godot being Open Source. We knew that we needed custom modifications for destructible terrain, dynamic lightning, and support for thousands of swarm monsters. All this is rarely supported in any engine out of the box. Additionally most of our team was already familiar with Godot. +Paweł and I are teaching classes on simulations and game dev that are heavily based on Godot Engine mostly due to Godot being perfect for fast prototyping. +When you want to create a new feature for your game it might just take a few hours to see it will work. + +### Which parts of the game development process did you enjoy the most while working on your project? + +The most enjoyable part of the game development is of course implementing new features. We went over many iterations on all kinds of systems and elements. The process overall can get mundane sometimes, but once you finish your cool spear combo or flashy lava particles or extremely complex custom map editor that does wonders under-the-hood, looking at the final result and playing it is a very satisfying experience. Some of the features were added just because they were fun to code and have this “cool” factor about them. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +The most difficult part is to decide what features should be implemented and resist the urge of adding new features. Because we want to keep our game simple, yet we have many ideas that standalone are cool, but mashed up together may result in something that is not working well. We still don't know if the game is balanced enough, which is why we are on Early Access to check what works right and what doesn’t. We will tweak things based on player feedback as we want to make the game as good as possible. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +GDScript is my favorite as you can do a lot with a little bit of code. + +The scene system gives much needed flexibility to create your own building blocks that create a level when brought together. Overriding properties like script variables, or sprite color via modulate property, allows to make asset variations easily. + +Another thing that was quite useful is the option to quickly test shaders. Being able to see the results of a shader the moment you change some code makes development so much better. + +And finally Lumencraft would not be possible without Godot being open source. Having the option to add custom modules is just wonderful. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +We launch on Windows and Linux for now. We got the game working on Mac as well. Also Linux build works almost out of the box on Steam Deck console. + +Most of us use Windows for development, but we have one Linux developer. Our experience was mostly seamless, with the only problems emerging at C++ level due to compiler quirks between platforms. + +### Which challenges have you encountered when using Godot? + +We struggled a lot with proper multiple resolution support. While this is mostly straight-forward and well-documented, Lumencraft required the ability to change fullscreen target resolution and that wasn’t obvious to achieve, especially when multiple in-game effects are full screen shaders that needed to match the screen size and resolution. Because of that we are still missing support for different aspect ratios (for now at least). Because we all had the same system specs and didn’t test different setups. When we realized there was a problem, it was too close to the release date. + +### Which features would you like to see in future versions of Godot? + +We would like to make use of compute shaders and array uniforms in shaders. Much of our custom tools needed tricks to pass the data around. One example is the debris particles interacting with 2D terrain. That one was tricky. +An option to generate mipmaps from viewport textures is coming back regularly. Currently you can't do that and multiple VFX had to be dropped because of that. + +### Would you use Godot for a future project? + +We are actively waiting for the next Godot version. ;) +We like the freedom to modify source code and implement features on top of C++ code base. We hope to upgrade Lumencraft to Godot 4 in the future. + +___ + +*Lumencraft is available on [Steam](https://store.steampowered.com/app/1713810/Lumencraft/) and [GOG](https://www.gog.com/en/game/lumencraft) for Windows, Linux and Steam Deck.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-ben-kurtin-fnf-vr.md b/collections/_article/godot-showcase-ben-kurtin-fnf-vr.md new file mode 100644 index 0000000000..ca9d76ec64 --- /dev/null +++ b/collections/_article/godot-showcase-ben-kurtin-fnf-vr.md @@ -0,0 +1,77 @@ +--- +title: "Godot Showcase - Friday Night Funkin' VR developer talks about his experience" +excerpt: "We interviewed Ben Kurtin about his VR recreation of the hit rhythm game Friday Night Funkin', which is made with Godot!" +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/61e/c59/4ad/61ec594adad2c161680389.png +date: 2022-01-22 18:15:00 +--- + +Welcome to a Godot showcase developer interview! This week, we interviewed Ben Kurtin about his experience developing and releasing a VR recreation of the hit rhythm game *Friday Night Funkin'*. + +___ + +### Introduce yourself in a few sentences. + +Hi! I'm Ben Kurtin, better known as ThisIsBennyK on [YouTube](https://www.youtube.com/channel/UCu7zwXQxp4rHmGhW9Dmulkg), [Twitter](https://twitter.com/ThisIsBennyK), and [TikTok](https://www.tiktok.com/@this.is.bennyk). I've made several games in the past couple of years, with projects ranging from a simple 2D platformer to the very VR rhythm game being showcased here; and that was all done while I was self-taught. Now I'm currently going to college to, quite literally, learn how to make games. My secondary hobbies are graphic design and video creation, both of which are evident based on my social media. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Friday Night Funkin' VR (FNFVR) is a VR recreation of Friday Night Funkin' (FNF). FNF is the most recent smash hit indie rhythm game (which is also open source!), and it's like if DDR had the style of PaRappa the Rapper. FNFVR lets you experience all the cartoony glory the game provides for yourself: you get to see all the wacky characters up close; you get to be in the stylized environments they're in; and, of course, you get to jam out to the awesome songs while you're fighting for your life to spend time with your girlfriend. + +FNFVR has already been released for Windows and both Quests on [Itch](https://thisisbennyk.itch.io/funkin-vr) and [SideQuest](https://sidequestvr.com/app/4089/friday-night-funkin-vr), but me and my team are consistently working on updates to it whenever we've got the chance. In fact, we're already working on the 6th week (or level) from the original game as we speak. I've also been making a better engine for both 2D and potential 3D mods for FNF using Godot, which we will be porting FNFVR to. As for when the next update comes up... well, no promises, but hopefully by the end of January! + +### Your game got [some traction on YouTube](https://www.youtube.com/watch?v=QpgxxARRqxI) such as on channels like Weegeepie. Can you tell us a little about that experience? + +It's been surreal to see how much traction FNFVR has gotten. I couldn't believe my eyes when the Week 2 preview I posted on TikTok garnered a million views in just a few days. And to see quite a number of respected YouTubers play and enjoy the game is astounding. I've even seen some YouTubers that I used to watch as a kid play the game, and that's just crazy to me. I feel like I have to pinch myself whenever that happens! +I'm extremely thankful for anyone who's made a video about FNFVR. It means the world to me that you all wanted to play it and show it off. It's helped me kickstart a lot of opportunities, like my YouTube channel and quite a few new friends, and for that I'm eternally grateful! + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +All my life I've wanted to make video games, so I've dabbled in quite a few game engines, but most things I tried to make as a kid didn't get finished. I started trying to make complete game projects in high school with Unity, but I became frustrated using it. After graduating (around summer 2020), I decided to search for a game engine that was easier to use and still just as feature rich. That's when I happened to find Godot. Like with any new thing you try, it took me a little bit to understand the basics. But after completing my second game jam project with it and being actually satisfied with my results despite having only picked it up recently, I knew it was my engine of choice. + +### Why did you choose Godot for your project? + +Well, I had already been using Godot for around 6 months when I decided I was going to make FNFVR, so I figured it would be easier to work with an engine that I was already familiar with. Plus, this is actually my second VR game made in Godot, so I wanted to improve from my last VR project. And boy did I improve! +In general, I chose Godot because, like I said before, I wanted something easy to work with. Maybe it was also for a bit of that counterculture feeling, since even when I picked up the engine in 2020, Godot was a niche engine. Of course, now I've been hearing lots of talk about it. In fact, I know a few professional software developers who have been using Godot for their game projects for the same reason: it's easy! While it does take away from the nicheness of the engine, that's not a change that I mind. I'm glad that more people are starting to use it. + +### How was your experience building a VR game specifically? + +It's a lot tougher than making a 2D or a non-VR 3D game, that's for sure. Not because it's necessarily harder to program or harder to make assets for, but it's much, much harder to debug. You have to put on the headset, wait for it to wake up, hit F5 awkwardly with the headset on, and then kind of peer through the nose gap to see the info you get on screen. And if you run into an error, you have to take off the headset, put it in a safe place, edit the code, and then rinse and repeat this process until you get it running stably. Simply put, it's tedious and a pain in the butt. Despite that, the satisfaction you get from seeing your work come to fruition when you put on the headset is incredible! + +### Which parts of the game development process did you enjoy the most while working on your project? + +Like many other game developers, I enjoy seeing the final product come together harmoniously. This effect has been magnified during the development of FNFVR, because there's something magical about seeing a game you enjoy from a different perspective. Besides that, however, FNFVR has given me deep insight on how to make a good rhythm game. Over several iterations, I've learned how to make an extremely accurate timekeeper (usually referred to as the Conductor, similar to the person who keeps tempo for an orchestra), as well as a highly flexible note and lane system. These revised components will be making their way into an upcoming update for the game. I'm very proud of the work I did for those and had a lot of fun making them! I hope they can be reused in other Godot rhythm game projects that I make or that others make (since the code will be open source, in the spirit of FNF). + +### Which parts of the game development process did you find the most difficult to apply in your project? + +I'm very new to 3D game development, and I only had a little experience prior to FNFVR. It was an arduous process figuring out how to get the player model right. At first, I was going to use inverse kinematics, similar to how VRChat works, but fortunately one of my fellow VR enthusiast friends guided me in the right direction and suggested floating hands. Not only that, but with a bit of hindsight, I've figured out that the game is extremely unoptimized in so many different ways. I'm going to be fixing this very shortly with my newfound knowledge (such as: it's actually a bad idea to make every model local since all the data of each model is duplicated into text). + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +I've said this to others when talking about Godot, and I'll say it again: Godot is very good for making games quickly. The rapid and hotfix prototyping that Godot provides made it possible for me to learn the engine quickly and then make a VR game quickly. The first prototype of FNFVR was made in around two weeks if I remember correctly. Granted, I worked my butt off for those two weeks, but I guarantee you that trying to do the same thing in other VR-compatible game engines would have been a slog. Even besides FNFVR, almost every game in Godot has been made quickly and efficiently (even with my spaghetti code in earlier projects!), which is something I truly appreciate about the design of the engine and the editor. + +### Which challenges have you encountered when using Godot? + +I did encounter a few issues, mostly nitpicks, during the development of FNFVR: + +- Some documentation leaves something to be desired. For instance, the SkeletonIK node, a node that would be very useful for controlling a VR avatar, has zero documentation on it. Or the PCKPacker, which is useful for an upcoming update for FNFVR, does not have a great tutorial on how to use it, so I had to brute force my way into learning how it worked. +- Blendshapes / shape keys simply don't work in the GLES2 renderer. For those reading who don't know, blendshapes, or shape keys, are parameters that morph a part of a 3D model to have a different shape. It's typically used for facial animations, like lip sync. This means the faces of every character in the game, which are controlled by these blendshapes, do not work on the Quest. There does seem to be an open request to fix this, which I would implement myself if I was confident enough to debug an entire game engine. +- Animating 3D stuff in-engine. I had to write my own custom code just to be able to animate the 3D models myself. Fortunately, I now work with people who are better at animating than I am, but I did find it odd that 3D skeleton animation was not built-in like it was for 2D. +- By far the biggest challenge of the project was learning how to properly use (and then promptly almost never using) `yield` statements. Because they can't be interrupted or destroyed (which is bad for pausing and quitting out of levels), I've decided to use signals for almost every event I need to handle. While this does produce uglier code, it makes it more flexible and ultimately allows us to be more creative with levels! + +### You ported your game to the Quest. How was that experience? + +While the Quests have been a major step up in affordable and accessible VR, it's not fun to develop for the standalone side of them. Having to switch renderers, design and manage levels so that they look the same on both platforms, debug across devices, and do operating-system specific set-up is a slow and tedious process. This process is so slow and tedious that I might've given up on developing for the Quests if they didn't happen to have the largest share of all personal VR users (and incidentally, the large share of our player base). I can only hope that the move to OpenXR and the eventual release of Godot 4.0 makes it easier to develop for the Quest platform. + +### Which features would you like to see in future versions of Godot? + +Most of the features I already wanted to see in Godot are actually coming in 4.0, which I'm pretty happy about. If possible, having those blendshapes work in GLES2 would be great to have (unless 4.0 is coming soon enough to fix that problem). However, my #1 request would be for AnimationPlayers to have the same easing options as Tweens do; that would be very useful. Otherwise, Godot already packs quite the punch with the features it has, and I can't wait to see what you guys are working on in future updates! + +### Would you use Godot for a future project? + +If you ask some of my friends what they know about me, a couple possible answers are: "Ben never shuts up about Godot" and "Ben sounds like he's sponsored by Godot." I think that's a sufficient enough way to say "yes, absolutely!" + +___ + +*Friday Night Funkin' VR is available as a free download for Windows, Quest and Quest 2 on [Itch](https://thisisbennyk.itch.io/funkin-vr) and [SideQuest](https://sidequestvr.com/app/4089/friday-night-funkin-vr). The project's source code is also available on [GitHub](https://github.com/this-is-bennyk/Funkin-VR).* \ No newline at end of file diff --git a/collections/_article/godot-showcase-cheeseness-hive-time.md b/collections/_article/godot-showcase-cheeseness-hive-time.md new file mode 100644 index 0000000000..d3ad684a34 --- /dev/null +++ b/collections/_article/godot-showcase-cheeseness-hive-time.md @@ -0,0 +1,80 @@ +--- +title: "Godot Showcase - Hive Time developer Cheeseness talks about his experience" +excerpt: "We've invited Cheeseness to talk about his project, Hive Time. it was released in December 2019 and is available on Windows, macOS and Linux." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/602/e98/120/602e98120ec23097807599.png +date: 2021-02-18 15:30:00 +--- + +Welcome to the third developer interview following the [introduction of the Godot Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we've interviewed Cheeseness about his project [*Hive Time*](https://godotengine.org/showcase/hive-time). + +___ + +### Introduce yourself in a few sentences. + +My name is Cheese, and I'm an Australian independent game developer/Linux porter/freelance generalist based in the small island of Tasmania. I've been making games in some form or another for over thirty years now. + +I like to contribute to Free/Open Source Software projects when I have time, and release my own work under F/OSS and open culture licences when appropriate. I've even made some small contributions to Godot itself. I enjoy photography, playing guitar, and long, long walks in the wilderness. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +[Hive Time](https://cheeseness.itch.io/hive-time) is a bee-themed management sim, which invites players to construct a generational bee hive and manage its population's diversity. It's cute, silly, and has a big heart. + +I released Hive Time for Linux, Mac, and Windows on the 12th of Beecember 2019, and shipped a [large update](https://cheeseness.itch.io/hive-time/devlog/147869/v11-the-informational-update) coinciding with World Bee Day on the 20th of May 2020. + +Hive Time is $10, but in the interests of making sure it's still accessible to people who aren't able to afford that and to explore the [dynamics of pay-what-you-want models](http://cheesetalks.net/hive-time-finances.php), I decided to release it with a minimum price of $0. + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +I first came across Godot when backing The Interactive Adventures of Dog Mendonça & Pizzaboy on Kickstarter back in 2014, but I think the first project I used the engine for was a prototype for [Super Happy Fun Sun](http://shfs.twolofbees.com/) developed as part of a game jam in 2015. + +Over the years, I've worked on projects that have used GoldSrc (Half- Life 1's engine), Serious Engine, Unity, SLUDGE, Adventure Game Studio, jMonkeyEngine, Blender Game Engine, and SCUMM/Remonkeyed Engine. I've also worked on games that have been built from scratch or use frameworks rather than general purpose engines like SDL, SFML, and Allegro. + +For the past six years, I've been writing my own game engine called [Icicle](http://icicle-engine.org/), which is written in C/C++, using SDL and OpenGL. + +### Why did you choose Godot for your project? + +I'd previously attempted to make a 3D game in Godot in 2015 (it would have been a third person plafomer about a ladybug), but my initial experiments before the jam I was planning to use it for weren't yielding the kind of results I was after. + +The next time I had the opportunity to try again, Godot had come a long way, and I was able to develop the initial [Hive Time prototype](https://cheeseness.itch.io/hive-time-prototype) during a 10 day game jam. + +### Which parts of the game development process did you enjoy the most while working on your project? + +For me, the most enjoyable part of both making and playing Hive Time is sitting back and watching my little bees bumble arund and go about their business. + +I also loved going out to local honey farms to record bees, and it was wonderful to see/hear Peter's work on the soundtrack breathe extra life into the game. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +Broadly speaking though, the game came together with very few signficant design or production hurdles. I worked hard to lean on my existing development and project management experience and keep the game's development timeframes tight and overheads small. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +I felt like Godot enabled me to pull the core game together very quickly. The most attractive parts of the engine for me come from its nature as a Free/Open Source Software project and the ability that gives me to debug, fix, or modify the engine to suit my personal needs. + +I also feel more comfortable using free and Free tools because I can be confident that if others want to follow in my footsteps, financial or philosophical hurdles won't prevent them from doing so. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +I pretty much exclusively developed Hive Time on Linux, so I didn't have much opportunity to expose myself to the editor tools' multi-platform support. + +I'm glad that Godot allows me to deploy builds for all my supported platforms from my Linux build server without having to involve other operating systems or set up cross-compiling pipelines. + +### Which challenges have you encountered when using Godot? + +I've struggled a little with performance optimisation, and the now-addressed dangling variants bug likely caused the majority of unidentifiable problems that had been reported in the wild. + +Unclear or incomplete documentation has been a long time friction point for me. Things have definitely improved on that front over the years, though there's always room for improvement. These kinds of hurdles are rarely significant and the option to fall back on reading engine code is always there, but cumulatively, these can add up to be a reasonable time sink across a large project. + +### Which features would you like to see in future versions of Godot? + +I'd love to see an option to treat underscores as punctuation for the purposes of text navigation. I run custom editor builds that already do this, but that applies to all string handling engine-wide rather than just the editor tools, so it's been difficult to formulate that into a patch that I can contribute upstream. + +### Would you use Godot for a future project? + +I plan to! + +___ + +*Hive Time is available on [itch.io](https://cheeseness.itch.io/hive-time/) for Windows, macOS and Linux.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-fat-gem-primal-light.md b/collections/_article/godot-showcase-fat-gem-primal-light.md new file mode 100644 index 0000000000..284ea95234 --- /dev/null +++ b/collections/_article/godot-showcase-fat-gem-primal-light.md @@ -0,0 +1,81 @@ +--- +title: "Godot Showcase - Primal Light developer interview" +excerpt: "We've interviewed Fat Gem about their first released project Primal Light. It was released in July 2020 and is available on Windows, macOS and Linux." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/604/11f/d88/60411fd88eb88947959052.png +date: 2021-03-04 17:00:00 +--- + +Welcome to the fourth developer interview following the [introduction of the Godot Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we are interviewing the studio Fat Gem about their first game *Primal Light*. + +___ + +### Introduce your studio in a few sentences. + +Hi, I’m Shane Sicienski. My friend Jeff Nixon and I make games together under the name Fat Gem. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Primal Light is a linear 2D action platformer for Windows, Mac, and Linux. It was released on July 09, 2020 and is available on [Steam](https://store.steampowered.com/app/771420/Primal_Light/). + +In the game, you play as Krog, a one-eyed blue caveman wearing a red loincloth, who is on a quest to save his tribe from an evil moon god. + +The game features 10 challenging levels with arcade-style combat reminiscent of the 16-bit era. As you progress, you acquire new acrobatic abilities which allow you to overcome obstacles and enemies. Each level ends with a gruesome boss. + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +Around 4 years ago, I was learning how to program (in order to do natural language processing) when it suddenly dawned on me that I had probably learned enough to be able to make a game. I prototyped a little top-down Zelda clone and showed it to my friend Jeff one night while we were hanging out at his apartment. We were so excited by the prospect of making a game that he dove headfirst into pixel art and I into programming. That was around August 2017. + +We started making Primal Light in Python (using the [PyGame](https://www.pygame.org/news) module), but when we started getting serious about the project, we decided to shift to a full-fledged engine. + +I had seen Godot come up in comments on [Game Development Stack Exchange](https://gamedev.stackexchange.com/) with people describing it as “Pythonic”, so it seemed like a natural candidate for me. + +At that time, I didn’t have experience with any engines outside of PyGame, but since then I’ve become proficient in GMS2 and Unity, in addition to Godot. + +### Why did you choose Godot for your project? + +When we were deliberating on moving to a full-fledged engine, I had seen Godot come up in comments on [Game Development Stack Exchange](https://gamedev.stackexchange.com/) with people describing it as “Pythonic”, so it seemed like a natural candidate for me. The fact that I am also a big fan of Samuel Beckett didn’t hurt Godot’s chances with me. + +### Which parts of the game development process did you enjoy the most while working on your project? + +Jeff and I both enjoyed designing bosses and boss battles. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +Jeff and I were flying by the seat of our pants on this project, as it is our first game. We encountered difficulties all over the place, but our sheer excitement at making a game sustained us. We found level design intimidating at first, but, like lots of things, it becomes fun once you try to study it and learn its mysterious rules. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +Godot has a ton of strengths. A few come to mind. First, Godot uses the pixel as the native unit of measurement, which makes it ideal for 2D games. Second, Godot has a much better implementation of coroutines than other engines (and coroutines are a game developer’s best friend). Third, Godot’s signal system provides an out-of-the-box implementation of the observer pattern that is more intuitive that what you have in other engines (for example, using C# events). Finally, Godot has better animation tools than other engines I have worked with. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +We developed Primal Light on both Windows & Mac and had no issues whatsoever, even on old hardware (I started development on a 2008 MacBook). We built for Windows, Mac, & Linux, and found it a breeze, even accommodating Steam integration across all three platforms using the life-saving [GodotSteam](https://github.com/Gramps/GodotSteam) repo. Godot’s option to toggle between GLES2 and GLES3 also makes it easy to build for specific rendering architectures if needed. + +The only issues we encountered were some inconsistent capitalization in our filenames causing crashes on case-sensitive OSes, and using the same variable name in both a local and nested local context causing crashes on Mac (both easily fixed). + +### Which challenges have you encountered when using Godot? + +We had some thorny issues with pixel jitter when our camera would settle on the player, but I think that’s a cross-engine problem which plagues pixel art games in general. + +We tried to use Godot’s native Camera2D offset when implementing screenshake, but offset alone wouldn’t allow the viewport to traverse camera limits if the camera was adjacent to them. I filed that as a bug on GitHub and Godot devs fixed it in Godot 3.1 or thereabouts. + +We originally had Light2Ds littered throughout the game (for example, for candle effects), but it caused severe performance issues. This was a known issue for Light2Ds back then. I think I heard that Godot devs recently made strides in improving their performance, but I’m not certain. + +### Which features would you like to see in future versions of Godot? + +I think Godot has an excellent feature set as is, and I am typically a fan of minimalism. Some of the larger engines have bloat that irritates me aesthetically. + +I know some people would like to see a sprite editor in the engine (similar to what you have in GMS2), but I never encountered a use case for that in my own development. + +I recall a Twitter poll recently which asked Godot users what should be focused on in the near future. I voted for improvements to tilemap functionality, which was the frontrunner at least at that time. + +### Would you use Godot for a future project? + +One hundred times yes! + +___ + + +*Primal Light is available on [Steam](https://store.steampowered.com/app/771420/Primal_Light/) for Windows, macOS and Linux.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-garden-path-developer-talks-about-his-experience.md b/collections/_article/godot-showcase-garden-path-developer-talks-about-his-experience.md new file mode 100644 index 0000000000..16d799f254 --- /dev/null +++ b/collections/_article/godot-showcase-garden-path-developer-talks-about-his-experience.md @@ -0,0 +1,86 @@ +--- +title: "Godot Showcase - The Garden Path developer talks about his experience" +excerpt: "This week, we are interviewing Louis Durrant about his game The Garden Path. It will be released in Autumn/Winter 2021 for Windows, macOS and Linux." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/60f/9a7/b1e/60f9a7b1eb0ca060142976.jpg +date: 2021-07-22 16:30:00 +--- + +Welcome to another developer interview following the [introduction of the Godot Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we are interviewing Louis Durrant about his game [*The Garden Path*](https://godotengine.org/showcase/the-garden-path). + +___ + + +### Introduce yourself in a few sentences. + +Hi, I'm Louis Durrant, and I make games under '[carrotcake](https://carrotcake.studio/)'. I'm an illustrator living in Bristol, UK. The studio was me in my parent's attic to start off, but now it's me in a home-office, so we're making inroads. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +'The Garden Path' is really just the relaxed, whimsical social-sim I've always wanted on PC. Something slow-spaced that you can put on a podcast alongside, or just soak in the atmosphere - you know? + +I want to keep things fairly low-key, as this is my first real release. I'm hoping to release the game this autumn or winter, but I'm not rushing myself. I'll be supporting the game with more content after it's released, but I want it to feel like a polished product worth the price tag on release day. + +It will be a PC game at heart, but it is built from the ground up with a controller in mind. When the time is right, I think it would be an ideal game for the Nintendo Switch. + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +I lurk around a number of forums for open source software and Godot was always in the back of my mind. + +I remember opening it up many years back and having no idea where to start. + +I introduced myself to game development during my time at university studying graphic design. It was an artsy enough course that you could go ahead and do things like that. I started with Visionaire Studio because you can build something pretty substantial without any code, but it helped me understand the fundamentals. + +After I graduated in 2017 I told myself I'd start learning code and start learning Godot. + +Nowadays working in the engine feels right at home. + +### Why did you choose Godot for your project? + +I've been an advocate for open source software since I can remember, so Godot just seemed like the right fit. It's a good feeling knowing that my work isn't under the thumb of any kind of restrictive licensing. + +I also liked the idea of being an early adopter at the time. There was buzz around the engine, but it still needs those flagship titles that people can point to. And that's really very important, because if people are asking 'how was this made' and the answer is something open source, that's a big accomplishment. + +Something for me to aspire toward, anyway. + +### Which parts of the game development process did you enjoy the most while working on your project? + +As ever the joy of game development is bringing each puzzle piece together and seeing the final result. I love art, animation, soundtracking and programming, and those are all tools to capture a certain mood I'll have in mind. + +It's when each of those elements comes together in the way you intended, or perhaps even in a way you hadn't, and it's like a toy springing to life with it's own quirks and character. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +The raw maths. Not that there's an awful lot with a game like mine, but it's surprising how often you need a certain formula to return the number you're after. + +I spent most of my maths lessons watching crows out the window. I'm fortunate enough to have some pretty mathsy friends who I can ping my questions to. They'll tell me 'use modulo' or 'you want the absolute number for that' and I learn something new. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +I love how modular everything feels. Just in the last few months or so I've started to really appreciate how you can break everything down, and start building your own systems within the engine. + +Once I started understanding how you can make your own objects and resources, you can really start creating flexible methods tailored to your own game. + +### Which challenges have you encountered when using Godot? + +Godot is still young, which is part of its appeal, but there isn't always an easy solution for certain complex things you don't necessarily need. The community is great and it's growing, but it isn't as big as more established engines, so the answers aren't always out there when you go looking. + +I spent longer than I care to admit trying to get a white outline drawn over multiple sprites, but couldn't for the life of me get it to work. Something to do with a BackBufferCopy node, I got that far. + +### Which features would you like to see in future versions of Godot? + +Honestly I feel spoiled by the engine already, so I'd feel cheeky asking for much more. Directional shadows for 2D are already on the roadmap I believe, and that would be a big step up for my game's visuals. + +And hey, being able to adjust easing in the AnimationPlayer of multiple properties would be mint. + +Hat's off to everyone working on the engine, I wish I had an ounce of the mental wherewithal to build or contribute to a project like this. Keep up the great work, and keep keeping it real. + +### Would you use Godot for a future project? + +In a heartbeat. + +___ + + +*The Garden Path is expected to be released in Autumn/Winter 2021. It currently has an ongoing [Kickstarter campaign](https://www.kickstarter.com/projects/fromcarrotcake/the-garden-path-a-hand-illustrated-slice-of-life-sim-game) at the time of publishing this interview.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-john-watson-gravity-ace.md b/collections/_article/godot-showcase-john-watson-gravity-ace.md new file mode 100644 index 0000000000..de1c80f6e0 --- /dev/null +++ b/collections/_article/godot-showcase-john-watson-gravity-ace.md @@ -0,0 +1,63 @@ +--- +title: "Godot Showcase - Gravity Ace developer talks about his experience" +excerpt: "This week, we are interviewing John Watson about Gravity Ace, a 2D multi-directional gravity shooter. It was released in October 2020 in early access and is available on Windows and Linux." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/607/b66/7e9/607b667e93a46491184773.png +date: 2021-04-18 14:50:00 +--- + +Welcome to another developer interview following the [introduction of the Godot Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we are interviewing John Watson about the game [*Gravity Ace*](https://godotengine.org/showcase/gravity-ace). + +___ + +### Introduce yourself in a few sentences. + +Hi, I'm John, I'm a (mostly) solo game developer making games that I want to play. I've been making games as a hobby since 2013, mostly by participating in weekend or month-long game jams. My first game was for the One Game A Month challenge. Now I'm working on my first commercial project. My formal training is in programming but I've always been interested in art and music as well. Game development is fantastic because it allows me to bring all of that together into a single project. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Gravity Ace is a 2D multi-directional gravity shooter (cave-flyer). It's a love letter to Thrust and Gravitar and all of the amazing games they inspired. Remember Thrust? Most people don't but I loved that game and I really wanted to play it again. Gravity Ace is inspired by Thrust but adds a lot of modern touches and generally brings the art, sound, and gameplay up to modern standards. It's currently in Early Access with an expected release date in 2021. Linux and Windows. You can wishlist or buy it on [Steam](https://store.steampowered.com/app/1003860/Gravity_Ace/) or [itch.io](https://jotson.itch.io/gravity). + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? Why did you choose Godot for your project? + +I've made games in a bunch of different engines and frameworks and languages over the years. Haxe, Lua, JavaScript, Java. Those experiences were great but they all fell a bit short in terms of ease of use or features or productivity. I think I discovered Godot not long after the project was open sourced. At the time I was looking for an engine with a built-in visual editor because I was tired of moving things around by typing coordinates in code. I needed something to speed up my workflow and make it less cumbersome to quickly prototype ideas. + +Of course I tried Unreal and Unity but as a full-time Linux user I was unsatisfied with their lack of official support. And those engines felt just so... massive. I chose Godot for a lot of reasons. It's small, fast, and has first-class support for Linux. It has all the features I need for the games I want to make. It's open source with great leadership and community. And I think it has a bright future. + +### Which parts of the game development process did you enjoy the most while working on your project? + +One of the reasons I like making games is because it allows me to combine several of my interests into one project. I enjoy programming. But I also enjoy making art and music. So I tend to bounce around between those things. That's one of the benefits of working on a game solo. I get to do everything. (That's also one of the drawbacks of working on a game solo.) So if I get tired of programming I can switch to animation or sound or music. It keeps things interesting. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +I mean... My mind went immediately to the cliché answers to this question but really, when I think about it deeply, I can't think of anything about game development that is easy. It's all difficult and it's hard to pick one thing. Yesterday I was working on a bug that is caused by some combination of timers and bad math that I still haven't solved yet. I've thrown away more art than is in the actual game. + +Game development is hard, right? It's not the engine or the programming or anything like that... it's the process. Designing things, thinking deeply about how things should work, making interesting artwork, it's all hard. But it's the kind of struggle that's fun to do if you have a certain kind of personality. Like, I guess there are people who climb mountains? For fun? That's not easy and it's certainly not me but I get it. Would I make games if it was easy? Probably. Maybe. But it's hard to imagine. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +I think without Godot I'd be much farther behind where I am now. Godot just works in a way that meshes with how I like to think and work. I'd be much less productive for sure. + +The 2D workflow is pretty great. Just drop some images in and drag them onto the canvas, attach a script, write a few lines of GDScript and you've got the beginning of a game. Modifying assets is seamless. And the node tree is super powerful. Reusing scenes in other scenes allows me to do a lot of stuff quickly and visually that would have been much more cumbersome in other frameworks. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +This is a huge selling point for me. Being able to build for multiple platforms from a single code base and all from a single machine is amazing. The fact that all of my builds finish in under a minute is icing on the cake. + +### Which challenges have you encountered when using Godot? + +Nothing out of the ordinary really. Every engine I've ever used has a few warts and bugs that you have to work around. + +### Which features would you like to see in future versions of Godot? + +Nice thing about an open source project is that you can see all of the open issues and the developers are very open about what they are working on. So I know better 3D support is coming, which I'm very excited about. I'm pretty happy with the 2D support as-is. New features are great but I'd almost like to see the devs focus on stability, performance, and improving the features that we already have rather than continue to work on new stuff. I'd love to be able to edit shaders in the main code editor instead of a dock. I'd also like to see better and more stable support for 2D lights. + +### Would you use Godot for a future project? + +Yes, absolutely. In fact, I already am. + +___ + + +*Gravity Ace is available on [Steam](https://store.steampowered.com/app/1003860/Gravity_Ace/) and [Itch.io](https://jotson.itch.io/gravity) for Windows and Linux. You can also follow its development on [Twitter](https://twitter.com/yafd).* \ No newline at end of file diff --git a/collections/_article/godot-showcase-justin-arnold-rpg-in-a-box.md b/collections/_article/godot-showcase-justin-arnold-rpg-in-a-box.md new file mode 100644 index 0000000000..c891d423e4 --- /dev/null +++ b/collections/_article/godot-showcase-justin-arnold-rpg-in-a-box.md @@ -0,0 +1,63 @@ +--- +title: "Godot Showcase - RPG in a Box developer talks about his experience" +excerpt: "We interviewed Justin Arnold about his project RPG in a Box, which is an engine made with Godot that lets you easily create 3D grid-based, voxel-style RPGs, adventure games, and more!" +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/61d/f21/37d/61df2137db710511123151.png +date: 2022-01-12 17:30:00 +--- + +Welcome to a new [Godot showcase](https://godotengine.org/showcase/) developer interview to start off the new year! This time, we asked Justin Arnold about his experience developing and releasing his project [*RPG in a Box*](https://godotengine.org/showcase/rpg-in-a-box). This "engine within an engine" demonstrates that Godot is not only capable for game development, but also for creating applications with complex user interfaces. + +___ + +### Introduce yourself (or your studio) in a few sentences. + +Hello! My name is Justin Arnold and I'm a solo developer working on RPG in a Box. I've always loved programming since my dad got me interested in learning BASIC on our C64 as a child. As I got older I developed a strong desire to build an RPG-focused tool that would allow others to easily create their own worlds and adventures. This idea has gone through several iterations over the past two decades and I'm excited to finally be bringing it to fruition through RPG in a Box! + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +RPG in a Box is an engine that lets you easily create 3D grid-based, voxel-style RPGs, adventure games, and more! I began developing it around the beginning of 2015. It was released into Early Access on August 12th, 2019 for Windows, Linux, and macOS. Games created with RPG in a Box can also be exported to these platforms. A free demo version is available on [Steam](https://store.steampowered.com/app/498310) and [Itch.io](https://zeromatrix.itch.io/rpginabox) if you'd like to check it out and get a feel for the current state of the engine! It includes all features found in the full version, with some limitations on map size/count and a splash screen on exported games. + +I also have a [Patreon](https://www.patreon.com/rpginabox) for those who are interested in supporting the development of RPG in a Box beyond a purchase of the software. + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +I first heard about Godot from a Slashdot article when the engine had reached its 1.0 stable version. I started playing around with it shortly after (around the beginning of 2015) as it seemed to be a great fit for what I wanted to create. I had some prior experience with Xith3D and jMonkeyEngine (alongside various UI frameworks like Swing and Eclipse RCP) while working on RPG Toolset, the Java-based predecessor to RPG in a Box. + +### Why did you choose Godot for your project? + +One of the primary aspects that drew me to try Godot was its built-in UI components, since it would allow me to easily build the various editors and interfaces that I needed while also supporting graphical elements like 3D viewports. The fact that it's open source and supports multiple platforms, as well as how lightweight the engine is, are all attractive aspects that made the choice even more straightforward. + +### Which parts of the game development process did you enjoy the most while working on your project? + +One of the most enjoyable and satisfying things has been getting to see the community bring their own game ideas to life through RPG in a Box. As programming has always been a passion of mine, coding new features and functionality into the tool and then seeing people use it to make something creative and imaginative is a wonderful part of the process! + +### Which parts of the game development process did you find the most difficult to apply in your project? + +Being a solo developer, I'd say the most difficult part is testing new functionality and changes to ensure they won't break something else, especially as the tool continues to grow. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +Having access to a large variety of built-in UI components that work seamlessly with the rest of the engine has been extremely helpful. I love the flexibility of the scene system and GDScript, and how the API seems to pretty much always have the specific functionality I'm looking for. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +Great! It's been simple and straightforward to compile the binaries and release the software for Windows, Linux, and MacOS. It's also convenient since it allows RPG in a Box users to easily export their created games to multiple platforms as well. + +### Which challenges have you encountered when using Godot? + +None that I can think of! Using Godot for my project has been a great experience overall. + +### Which features would you like to see in future versions of Godot? + +Nothing in particular at this time. I believe I will be more than happy with everything that Godot 4.0 is bringing! + +### Would you use Godot for a future project? + +I would definitely use Godot for any future projects! Of course, that's if I ever get around to it, as I'm quite sure I have enough ideas for RPG in a Box to last a lifetime, haha. And as Godot just keeps getting better and better, there will be even more opportunities to expand RPG in a Box further, which is really exciting! + +___ + + +*[RPG in a Box](https://www.rpginabox.com/) is available on [Steam](https://store.steampowered.com/app/498310/) and [Itch.io](https://zeromatrix.itch.io/rpginabox) for Windows, macOS and Linux.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-leocesar3d-human-diaspora.md b/collections/_article/godot-showcase-leocesar3d-human-diaspora.md new file mode 100644 index 0000000000..3bb00d63aa --- /dev/null +++ b/collections/_article/godot-showcase-leocesar3d-human-diaspora.md @@ -0,0 +1,61 @@ +--- +title: "Godot Showcase - Human Diaspora developer interview" +excerpt: "This week, we are interviewing Leonardo \"Leocesar3D\" Veloso about their game Human Diaspora. It was released in September 2020 in early access and is available on Windows and Linux." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/604/a91/97d/604a9197d1523072023513.jpg +date: 2021-03-11 21:00:00 +--- + +Welcome to another developer interview following the [introduction of the Godot Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we are interviewing Leonardo "Leocesar3D" Veloso about their game [*Human Diaspora*](https://godotengine.org/showcase/human-diaspora). + +___ + +### Introduce yourself in a few sentences. + +My name is Leonardo Veloso and I am a 3D artist working on TV broadcasting in Brazil, in my spare time I am a hobbyist game developer. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Human Diaspora is a First-Person Shooter where the player must conquer the colony planet to save humanity. It is available for Linux and Windows and I released it in September 2020. [You can find it as Early Access in Steam.](https://store.steampowered.com/app/1395420/Human_Diaspora) + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +I found Godot when I looked up for a FOSS alternative for Unity/Unreal and first used it in October 2019. I began making games with Game Maker 8, then switched to Unity to create my first 3D game and kept using it until I tried Godot. Now I use Godot as my only Game Engine tool. + +### Why did you choose Godot for your project? + +Foremost, Godot is FOSS. It entails freedom to dispose of my game projects as I best see fit without worrying about the intricacies of software licenses. And while learning to use it, I realized it already had the necessary set of tools to pull out my game ideas. The node architecture with the concept of scene within scenes and the straightforward way of scripting with GDScript sealed the deal for me. + +### Which parts of the game development process did you enjoy the most while working on your project? + +I just love to see my 3D models come to life inside the game engine, walk around, look at the details, and of course, generate interactivity for them is pure bliss and joy. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +I am probably not alone on this one: Game Design. Creating a fun game is second nature to some people, but for me, it is the most challenging aspect of game creation. What is fun for me maybe is bad design, not fun, or lacking for most of the players? + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +I love the iterative approach of Godot to test ideas as fast as possible: import a model, create a sub-scene for it with its associated specialized scripts, hit play and iterate over. + +### How do you find Godot’s multi-platform support, both for the editor and your final project? + +In my case, it is just a button press away to see my game running on Linux/Windows/Mac. + +### Which challenges have you encountered when using Godot? + +Debugging: some errors pop here and there, and it is really hard for me to trace its roots or if it is an engine bug. Sometimes their description is lackluster and confusing. I am staring at you shader compilation and parenting errors. + +### Which features would you like to see in future versions of Godot? + +I want the “Make it look beautiful” button implemented. Jokes apart, as a 3D artist I want hassle free look and feel configuration of 3D scenes. The PBR approach associated with groundbreaking dynamic/static global illumination, environmental effects as volumetric lighting, realistic post-processing effects, and of course, everything working together in an optimized and performant manner. Specially when 4K monitors may become the norm in the near future. + +### Would you use Godot for a future project? + +Of course, I’ll stick with it! I believe the game engine has a bright future and I want to be part of it. Showing off of what the tool is capable of and contributing to its growth through my own games, reporting and tutorials. + +___ + + +*Human Diaspora is available on [Steam](https://store.steampowered.com/app/1395420/Human_Diaspora/) for Windows and Linux. You can also follow its development on [Twitter](https://twitter.com/Leocesar3D).* \ No newline at end of file diff --git a/collections/_article/godot-showcase-little-red-dog-games.md b/collections/_article/godot-showcase-little-red-dog-games.md new file mode 100644 index 0000000000..42645a36f0 --- /dev/null +++ b/collections/_article/godot-showcase-little-red-dog-games.md @@ -0,0 +1,60 @@ +--- +title: "Godot Showcase - Little Red Dog Games talk about their experience" +excerpt: "This week, we've interviewed Little Red Dog Games' lead developer Ryan Hewer about their latest project, Rogue State Revolution." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/5fd/8c9/92b/5fd8c992b68a7578144586.jpg +date: 2020-12-15 14:30:00 +--- + +Welcome to the first developer interview following the [introduction of the new Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we've interviewed [Little Red Dog Games](https://www.littlereddoggames.com/)' lead developer Ryan Hewer about their latest project, [*Rogue State Revolution*](https://godotengine.org/showcase/rogue-state-revolution). + +___ + +### Introduce your studio in a few sentences. + +We're [Little Red Dog Games](https://www.littlereddoggames.com/)! We're a commercial developer that has been developing deep strategy games with despotic roosters and snarky surveyor probes for almost a decade now. + +We'd love to show off [Rogue State Revolution](https://store.steampowered.com/app/1145340/Rogue_State_Revolution/), which will be debuting for Windows and Linux in late February 2021. As President of the People's Republic of Basenji, you must appoint ministers and make sure they stay loyal. Build roads, factories, nuclear power plants and more, if you can afford it. Anything can happen: meteor strike, a pandemic, a cane-toad infestation, a robot apocalypse... if you can imagine it, there's a good chance that it's hiding somewhere in this game, waiting to be discovered. Your role is to care for your society, but a growing rebellion threatens to remove you from power. The game has lots of FMV, beautiful 3D visuals and represents a huge creative effort over the past two years. [You can check it out on Steam](https://store.steampowered.com/app/1145340/Rogue_State_Revolution/). + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +We've worked with other engines and frameworks before, but we stumbled upon Godot while actively looking for new game engines to try out with strong Linux support in 2015. We started with version 2-point-something and have delighted to see the engine grow and mature at the same pace as our own ambitions. + +We published two games with Godot already, [Deep Sixed](https://store.steampowered.com/app/591000/Deep_Sixed/) in 2018 and [Precipice](https://store.steampowered.com/app/951670/Precipice/) in 2019. + +### Why did you choose Godot for your project? + +Well, we've been using Godot for years and have grown very familiar with every little nook and cranny of the engine. Whenever the topic of switching comes up, we look around and it's clear that this free, open-source, incredibly versatile engine meets all our needs and we can't think of a good reason why we would need to. The node and scene architecture lets us design our games based on what we think makes sense for development, rather than forcing us into how an engine would want us to structure things. + +### Which parts of the game development process did you enjoy the most while working on your project? + +I think most of us agree that the most fun is in the early stages when you're fleshing out the design basis, building the foundations and implementing the basic structure of the game code. This is the time that every little addition feels like a big step and the progress is measured in miles rather than inches. It's easy to see why people love to write tutorials and conceptual-proofs, it's so rewarding! + +### Which parts of the game development process did you find the most difficult to apply in your project? + +We've struggled a little with harmonizing the asset importation pipelines between Blender, Maya and other 3D tools software, and developing games with very large object counts has made optimizing for speed quite a challenge (though admittedly, that would also be a challenge regardless of what engine we were developing in). + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +We love how Godot's scene structure emphasizes getting things done quickly and flexibly. Writing editor plugins and custom nodes is very useful, and if there is ever something that we want to tackle that it's in the main branch, there is nothing stopping us from cracking the thing open and building our own solutions to whatever problems we might encounter. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +The platforms that Godot supports by default all work very well, especially the desktop platforms, where it shines. We've got a console partnership that we'll be excited to reveal soon that has gone very smoothly. We have very little experience with mobile or HTML5 development. + +### Which challenges have you encountered when using Godot? + +Importing 3D assets and animations can sometimes be a pain. Even though the compatibility with various formats has improved lately, we're still running into issues with UV maps or shape keys from time to time, which are typically resolved by trying different file formats until one of them does the job in the matter intended. We have also encountered difficult-to-trace crashes in our exports that are exceedingly difficult to debug because they are not captured in the release build. + +### Which features would you like to see in future versions of Godot? + +There's a short-list of GDScript optimizations we're looking forward to and improvements to the asset importation pipeline is welcome. Can we bring back particle attractors? Oh, and the themes system could use a bit of a restructuring. Like everybody else, we're extremely excited about what is coming with Godot 4.0 and the road is now paved for us to pursue some really beautiful 3D products in the future. + +### Would you use Godot for a future project? + +You can count on it and we have already broken ground on the next big thing in Godot. In our opinion, there are no perfect engines, just preferred tools for certain kinds of jobs. For us, Godot has always been our preferred tool for the kinds of games we like to develop. + + ___ + +*Rogue State Revolution can be wishlisted on [Steam](https://store.steampowered.com/app/1145340/Rogue_State_Revolution/) and will be available on Windows and Linux.* \ No newline at end of file diff --git a/collections/_article/godot-showcase-monolith-of-minds-resolutiion.md b/collections/_article/godot-showcase-monolith-of-minds-resolutiion.md new file mode 100644 index 0000000000..be330ed297 --- /dev/null +++ b/collections/_article/godot-showcase-monolith-of-minds-resolutiion.md @@ -0,0 +1,64 @@ +--- +title: "Godot Showcase - Resolutiion developer Monolith of Minds talks about their experience" +excerpt: "We've interviewed Monolith of Minds about their latest game Resolutiion. It was released in May 2020 and is available on Windows, macOS, Linux and Nintendo Switch." +categories: ["showcase"] +author: Hugo Locurcio +image: /storage/app/uploads/public/600/74c/0ca/60074c0ca1012683594514.png +date: 2021-01-19 20:30:00 +--- + +Welcome to the second developer interview following the [introduction of the new Showcase page](https://godotengine.org/article/new-showcase-for-projects-made-with-godot)! This week, we've interviewed Monolith of Minds about their latest game [*Resolutiion*](https://godotengine.org/showcase/resolutiion). + +___ + +### Introduce your studio in a few sentences. + +We’re Monolith of Minds, two brothers from Germany who set out to tell tall tales of stray heroes and kind monsters. + +### Introduce your project in a few sentences: description, supported platforms, release date, etc. + +Our first game “Resolutiion” was released in May 2020 on [Steam](https://store.steampowered.com/app/975150/Resolutiion/), [Good Old Games](https://www.gog.com/game/resolutiion) and [Nintendo Switch](https://www.nintendo.com/games/detail/resolutiion-switch/). + +Five years in development, Resolutiion tells the story of the soldier Valor and his AI Alibii’s journey through a 2D dreamworld of lovely pixels, dirty jokes and badassemotional tunes, inspired by classic Zelda and similar action-adventure-games. + +### How did you discover Godot? When did you start using it? Do you have prior experience with other game engines? + +We love to rummage in the software world, digging up tools that help us tell our stories better. While we explored some more or less popular engines earlier, we love Free and Open Source Software, so naturally we came across Godot and fell in love with it right from the start. + +### Why did you choose Godot for your project? + +Developing with Godot is very easy. The core functionality can be picked up quickly and the engine is powerful enough to accomplish everything we were looking for in our game. Also the community is awesome and creates plenty of valuable tutorials and guides. + +### Which parts of the game development process did you enjoy the most while working on your project? + +Since we had no previous experience in game-development, learning everything from scratch was the biggest challenge but also the greatest pleasure. Seeing all those tiny splashes of color coming together into forming a full picture certainly was an amazing experience. + +### Which parts of the game development process did you find the most difficult to apply in your project? + +I guess we struggled quite a bit with animation and cut-scenes: these things always seem so simple in your mind, but turn out to be an endless sequence of tiny steps, each one just leading into more uncertainty. + +While Godot’s animation editor hits a sweet-spot between accessibility and complexity, we tried to cut corners every time a new scene emerged. After blaming each other for the shitty job, eventually we took a deep breath and put in the handiwork every decent cut-scene demanded. + +### How has Godot helped you advance on your project? Which aspects of Godot do you consider to be its strength? + +We have a fable for Python, therefore can appreciate GDScript a lot. For an iterating workflow the scene-system and its flexibility is a master piece in software design. + +### How do you find Godot's multi-platform support, both for the editor and your final project? + +Having such a full fetched editor run on Linux was probably a big selling point for us when we started. Also being able to export to all PC platforms, iOS and Android is definitely one of Godot’s strengths. + +### Which challenges have you encountered when using Godot? + +None, haha. + +### Which features would you like to see in future versions of Godot? + +Porting the game to the Nintendo Switch worked out fine, since we had Lone Wolf Technology to back us up. However, so far we haven’t found a way to get the game running on any of the other big consoles, such as PlayStation and Xbox. Better console integration is definitely something we are looking forward to. + +### Would you use Godot for a future project? + +Definitely, yes. Godot’s open source philosophy, fast development cycle and indie-friendly community make it an obvious choice for us. We have already started work on our second video game, and hope to share some first glimpses in early 2021. + +___ + +*Resolutiion is available on [Steam](https://store.steampowered.com/app/975150/Resolutiion/), [Good Old Games](https://www.gog.com/game/resolutiion) and [Nintendo Switch](https://www.nintendo.com/games/detail/resolutiion-switch/).* \ No newline at end of file diff --git a/collections/_article/godot-slides-gamified-slideshows-with-godot.md b/collections/_article/godot-slides-gamified-slideshows-with-godot.md new file mode 100644 index 0000000000..2c80151e5b --- /dev/null +++ b/collections/_article/godot-slides-gamified-slideshows-with-godot.md @@ -0,0 +1,61 @@ +--- +title: "Godot Slides: gamified slideshows made in Godot" +excerpt: "Build beautiful and gamified presentations with Godot Slides 2.0! The project ships with a 10 minutes multilingual pitch for you to give at gamedev meetups and other events, to introduce students to the engine... It's all drag-and-drop and, as you'd expect, open source." +categories: ["news"] +author: Nathan GDQuest +image: /storage/app/uploads/public/5bb/5f3/86b/5bb5f386bf45c464125655.png +date: 2018-10-05 17:00:00 +--- + +Last year, I was invited to present Godot 3 at a few venues in France: + + + + + +Making good presentations takes a **lot** of time, and I felt fellow teachers and in the community could reuse this one. + +As Godot has an international community, we would need to translate the slides and to use a technology that would allow us to improve it over time. Traditional slideshow programs are not designed for that, so they were out of the question. + +It turns out there's a mature technology that would allow us to create many translations with ease, to showcase interactive game demos, and lot more than that: **the Godot engine itself**. That is how [Godot Slides](https://github.com/GDquest/godot-slides) was born. + +Long story short, the first version was tricky to use. Although it was available in seven languages, the presentation was a little too long and technical. But some of you used it all around the globe, showing there was a need for it. So... + +## Better, Faster, Stronger: Godot Slides 2.0 + +Slides 2.0 is a **complete makeover** of the slideshow system: it is now entirely **drag-and-drop**, it's **modular and extensible**, it uses Godot's built-in translation system, the engine's UI system, and it's easier than ever to insert game demos inside of your slides! + + + +You can even change the language in real time if, like me, you have to give it into two languages at the same time. + + + + +## Godot Power pitch: a 10 minutes intro to the engine + +Slides ships with a 10 minutes introduction to Godot, a few of its flagship features, and information on how to get started with the engine: + + + +It's a short talk you can give at gamedev meetups, or for longer presentations, to get everyone on the same page before showcasing the editor for instance. The Power Pitch is still a little technical, with a few slides targeted at developers. But as it's short, it should not be too dull either. + +## New languages and better pictures: we need your help! + +At the time of writing, the presentation is already available in English, French, Japanese (written by me, so it needs proofing), and Spanish thanks to Antonio Torres Moríñigo. + +Here's a video guide to contribute a new language: + + + +Even if you're not familiar with Git, but you would still like to do translations, you can still contribute as explained in the tutorial, be part of the project history, and appear in the contributors' tab! + +Please help us translate it into new languages! It will help people in your community cover the engine in their native language. This contribution will count towards your Hacktoberfest progress as well. + +We're also [looking for beautiful pictures](https://github.com/GDquest/godot-slides/issues/33) of the editor with professional grade assets, to not only showcase some of the latest features in Godot 3.1 but to hopefully impress people. + +You can get [Slides 2.0 project on GitHub](https://github.com/GDquest/godot-slides) right now (please give it a star to help more people find it). + +When you give the presentation somewhere, feel free to ping me on Twitter [@Nathan_GDquest](https://twitter.com/NathanGDquest)! I'd love to know if people are using it! + +Thank you kindly for your time. \ No newline at end of file diff --git a/collections/_article/godot-sprint-and-user-meeting-barcelona-june-2022.md b/collections/_article/godot-sprint-and-user-meeting-barcelona-june-2022.md new file mode 100644 index 0000000000..08a8075d4f --- /dev/null +++ b/collections/_article/godot-sprint-and-user-meeting-barcelona-june-2022.md @@ -0,0 +1,46 @@ +--- +title: "Godot Sprint and User Meeting Barcelona June 2022" +excerpt: "After a couple of years of online-only events, we are bringing back some in-person Godot events. More precisely, today we are announcing two events taking place at Barcelona: a Godot Sprint for contributors (June 2nd & 3rd) and a Godot User Meeting (June 4th). Both events will be free of charge." +categories: ["events"] +author: Joan Fons +image: /storage/app/uploads/public/626/a6c/7d0/626a6c7d07e5f570805755.png +date: 2022-04-28 11:52:45 +--- + +After a couple of years of online-only events, we are bringing back some in-person Godot events. More precisely, today we are announcing two events taking place at Barcelona: a Godot Sprint for contributors (June 2nd & 3rd) and a Godot User Meeting (June 4th). Both events will be free of charge. + +**Please fill out [this form](https://forms.gle/mprhe1GHHThAWy9Z6) if you intend to join any of the two events.** + + +## What are Godot Sprint and Godot User Meeting? + +### Godot Sprint - June 2 & 3, 2022 (10:00 to 19:30) + +The Godot Sprint is a two-day event dedicated to engine contributors. As we usually work together online and discuss via Rocket.Chat or GitHub, we use opportunities like Godot Sprint to finally talk together IRL, which lets us discuss a number of technical topics and reach consensus much faster. + +So this event is mostly meetings focusing on specific contribution-related topics, such as the development roadmap, how to improve our workflows, onboarding of new contributors, as well as many technical topics which are of interest to the attendees. + +And of course this is a great opportunity to get to know each other better, which also greatly improves our ability to contribute efficiently towards common goals and make Godot an ever greater engine. + +If you're not a contributor yet but would like to become one, or are curious about a community-driven FOSS project operates, you are welcome to attend the Godot Sprint too. + +The Godot Sprint will take place at the Lleialtat Santsenca space in Barcelona. + +### Godot User Meeting - June 4, 2022 (10:00 to 20:00) + +The first official Godot User Meeting will be a full day event, taking place on June 4th at the Lleialtat Santsenca space in Barcelona. It will be a meeting point for Godot users and engine contributors in which to share experiences and get to know each other. + +We mostly invite Godot users from Barcelona and the neighboring regions to join us for a day, meet each other and core contributors after the Sprint. There will be some space for game demos and a few talks by community members, which we will detail as the event gets closer. + +## Practical information + +### COVID precautions +We will follow the requirements of the Spanish administration, as well as impose our own face mask and/or testing requirements for the safety of attendees. If COVID cases/ICU bed occupations were to spike before/around our event, it would be cancelled. + +### Venue's address +La Lleialtat Santsenca +C/ Olzinelles 31, Baixos +08014 Barcelona + +### Car restrictions +If you plan to come by car, be aware that the city of Barcelona has specific restrictions to limit traffic, more info [here](https://www.zbe.barcelona/en/zones-baixes-emissions/vehicles-afectats.html). \ No newline at end of file diff --git a/collections/_article/godot-web-export-progress-report-4.md b/collections/_article/godot-web-export-progress-report-4.md new file mode 100644 index 0000000000..02af071456 --- /dev/null +++ b/collections/_article/godot-web-export-progress-report-4.md @@ -0,0 +1,83 @@ +--- +title: "Web Editor beta, AudioWorklet, GDNative and more!" +excerpt: "The Web Editor reaches beta (3.2.4 beta 4), GDNative lands on the web, thread-enabled HTML5 builds now come with an improved audio driver using the AudioWorklet API." +categories: ["progress-report"] +author: Fabio Alessandrelli +image: /storage/app/uploads/public/5fe/1bf/c80/5fe1bfc80c475551734903.png +date: 2020-12-24 17:00:00 +--- + +Howdy Godotters! The year is almost over and it's about time we give you some news about the Web Editor and the HTML5 export. + +It's been a very fruitful year for Godot on the Web since the announcement of the first [web editor prototype](https://godotengine.org/article/godot-editor-running-web-browser). +As expected in the rationale of the original post, this has produced a lot of improvements to the HTML5 export in general, including support for threads, file drag and drop, LTO for smaller and faster builds, low-processor mode with optional lower framerate, and better control over audio output latency and mix rate. See the [second](https://godotengine.org/article/godot-web-progress-report-2) and [third](https://godotengine.org/article/godot-web-progress-report-3) reports for more details. + +With this new report, as you may know if you checked out the last [Godot Live Q&A](https://www.youtube.com/watch?v=zGmCbnE0UqA), we're happy to announce that we have added optional **GDNative support** in HTML5 exports, that the optional **Thread support** now comes with an improved audio driver using the **AudioWorklet API**, and that the **Web Editor has reached the beta stage**. + +Optional GDNative/Threads support +================================= + +If you tried out Godot [3.2.4 beta 4](https://godotengine.org/article/dev-snapshot-godot-3-2-4-beta-4) you might have noticed that the HTML5 export now has a new option called `Export Type`, which allows you to select either the `Regular`, `Threads`, or `GDNative` build. +Sadly, as of now, it is not possible to have an export that supports both GDNative and Threads. This is a [documentated limitation](https://github.com/emscripten-core/emscripten/wiki/Linking#pthreads-support) of the toolchain used to create the web export, and the WebAssembly specification itself. We are still investigating a workaround for that, but it's going to take some more time. + + + +Each export type has advantages and disadvantages, so you should choose depending on the scope and target of your game: + +- **Regular**: It is the most compatible acrosss browsers but does not support multithreading nor GDNative. +- **Threads**: Supports multithreading via the [Thread](https://docs.godotengine.org/en/stable/classes/class_thread.html) and [Mutex](https://docs.godotengine.org/en/stable/classes/class_mutex.html) classes and comes with a low latency audio driver that runs off the main thread preventing it from stalling or crackling when framerate drops or when changing scenes. However, it is currently not supported by all browsers (notably, Safari and thus iOS does not support it yet). It also requires some [extra care when distributing](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Security_requirements). +- **GDNative**: Supports GDNative libraries, allowing to write your code in other languages (e.g. C++) so you can further optimize your game and speed up execution, or bind external libraries to add extra functionalities to the engine. On the downsides, it will result in a bigger build size, thus increasing the startup time and memory usage. + +In general, my suggestion if you are not interested in mobile browser support is to use the *Threads* build to get the best performance with the smallest effort. +Hopefully, Safari's support for WebAssembly threads will ship next year thanks to the great work people are doing on the WebKit project, and even developers interested in HTML5 exports for mobile will be able to use the threaded version. + +Web Editor beta +=============== + +A new version of the web editor has been published at [this temporary address](https://godotengine.org/editor/). + +This is the first release tagged as "official" and based on the exact same sources of the other [3.2.4 beta 4](https://godotengine.org/article/dev-snapshot-godot-3-2-4-beta-4) builds. The goal is to keep the editor in sync with stable builds (starting from 3.2.4 stable). Old versions will still be available at dedicated locations. + + + + + +The highlights of the new version are: + +- A new improved look and feel of the HTML page that looks more integrated with the editor (special thanks to [Calinou](https://github.com/Calinou)). +- All importing issues should have been fixed. Most notably, audio samples can now be imported correctly, so the demo project now contains audio too. +- An old bug in the thirdparty Tween functions has been fixed that caused weird behaviors on HTML5 exports (and potentially other platforms too). +- Few bugs have been fixed in the JavaScript code that interfaces HTML5 exports with the browser (that glue-code has been mostly rewritten). + + +Honorable mentions +================== + +I would like to give a shout-out to the amazing work done by [dsnopek](https://github.com/dsnopek) and [lawnjelly](https://github.com/lawnjelly) on [WebXR](https://github.com/godotengine/godot/pull/42397) and [GLES/WebGL in Godot 4.0](https://twitter.com/lawnjelly/status/1336767514227957761) respectively. You well deserve the Web export medal of honor. + +Future work +=========== + +We feel like the web editor is almost ready to become stable, and plan to release it as such when 3.2.4 is released, but there are still few things that needs to be improved for web exports before I can refocus my work on some other ideas I've been sketching for networking and server exports: + +The HTML5-related **documentation** needs some love to be more in sync with the current status. + +**Gamepad** support on HTML5 is in an abysmal state, this is for many reasons. First of all the W3C specification is incomplete and does not allow to easily identify devices in a unique way. Additionally, the sheer amount of work required to support all possible devices is too much for browser vendors. +In an effort to improve the current situation, we plan to create a small addon that allows to remap the gamepad on the fly that you can bundle in your game, or send your generated mappings to us (so we can bundle them in future Godot versions). While this won't solve all the problems until the specification is improved and browser support gets better, it should allow for many more controller to work out of the box across different platforms. + +I've recently proposed a better way than `eval` to **communicate with JavaScript**, and that will need a tentative implementation. + +Stay tuned for the next announcement! + +References +========== + +[GDNative support](https://github.com/godotengine/godot/pull/44076) [(3.2)](https://github.com/godotengine/godot/pull/44170) + +[Threads/AudioWorklet](https://github.com/godotengine/godot/pull/43443) [(3.2)](https://github.com/godotengine/godot/pull/43454) + +[Importing issues](https://github.com/godotengine/godot/pull/44161) + +[Tween bug](https://github.com/godotengine/godot/pull/44197) + +[Editor style](https://github.com/godotengine/godot/pull/44221) [(3.2)](https://github.com/godotengine/godot/pull/44256) \ No newline at end of file diff --git a/collections/_article/godot-web-progress-report-2.md b/collections/_article/godot-web-progress-report-2.md new file mode 100644 index 0000000000..51a1a3d167 --- /dev/null +++ b/collections/_article/godot-web-progress-report-2.md @@ -0,0 +1,39 @@ +--- +title: "Godot web export progress report #2" +excerpt: "Godot is getting better export for the Web. While web technologies are not always suited to provide bleeding edge experiences, we do our best to let you exported game run as smoothly as possible on every platform." +categories: ["progress-report"] +author: Fabio Alessandrelli +image: /storage/app/uploads/public/5f4/8d5/175/5f48d51759192009283012.png +date: 2020-08-28 12:00:00 +--- + +Howdy Godotters! It's time for a long overdue update on the status of the HTML5 export and the web version of Godot in general. + +Many of the improvements made for the Web editor's [early prototype](/article/godot-editor-running-web-browser) have been merged in the `master` branch and backported to the `3.2` branch. Support for [`SceneTree.quit()`](https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-quit) and drag and drop of files via the [`files_dropped`](https://docs.godotengine.org/en/stable/classes/class_scenetree.html#signals) signal are already in the upcoming 3.2.3 release. + +The HTML5 export is also getting further improvements in the upcoming point releases: + +- Support for low processor usage mode, and FPS limiting (via `Engine.target_fps`). This is especially useful for non-game apps. +- Better control over the audio buffer size, to allow customizing the trade-off between audio delay and glitches on low-end devices (via the `audio/output_latency` and `audio/mix_rate` options in project settings and their overrides). +- Better keyboard support (see [GH-39298](https://github.com/godotengine/godot/pull/39298)). +- Link time optimization (LTO) for exported games (smaller size, shorter load). + +Along with these changes, I've been working to bring virtual keyboard support for the HTML5 export on mobile browsers. But this deserves a chapter of its own. + +Virtual Keyboards support +--- + +Sadly, web technologies do not allow us to directly show virtual keyboards on mobile devices. Like most of the time, when it comes to the web, one must (*sigh*) rely on hacks. + +To force the browser to show the keyboard, we need to rely on a hidden `` (or `
+ 
+ 
+