What is Reddit's opinion of
Godot Engine?
From 3.5 billion Reddit comments
➔ Godot Engine website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
This is fantastic! Just going to throw out a gentle signal boost for Godot, which is a fantastic community-developed open-source Unity alternative.
- Website: https://godotengine.org/
- Repos: https://github.com/godotengine
- Patreon: https://www.patreon.com/godotengine
Godot is a game engine similar to unity with many great features and a major upgrade coming in the next couple of months.
Anyone considering getting into game dev should seriously consider this engine.
And building the engine from source, to have all the new features immediately, is really easy.
Edit: source, not scratch
I didn't see anything specifically against destroying the logo in the press kit guidelines. (https://godotengine.org/press) They did mention not to distort the logo, but I'm pretty sure that just means to maintain the aspect ratio.
The game is called FOUNTAINS, as you can probably tell from the video. It's an action RPG, and if you want details/updates you can follow my twitter @PywellJohn
EDIT: The logo is licensed CC-BY-4.0, which allows transformation. I'm in the clear.
It may have a little ways to go but Godot is really coming into its own. Free and open source game engine with a pretty big community backing at this point.
I do all of my gaming on Linux and my experience is largely great. I don't do twitchy high-performance FPS shooters, though, so if that's your thing you may have different feelings. My current desktop has a Radeon Navi 10 (Radeon Pro W5700) and it basically just works and everything is awesome.
I would love to see more open source in games, but I think it'll happen mostly at the engine level (shoutouts to Godot and Bevy!). Games themselves I think are in a unique category as software where they are more like literature or art -- even the "code" parts. I think it might make sense to have them under licenses where they become open source five years after updates stop.
I recommend godot engine, it's open source, quite powerful for what it is, free, and if you get into it you can eventually look under the hood.
Main problem, still a low adoption rate means tutorials and support are rather sparse, but not non-existent.
If you mean an update on the release date, then no. But if you mean updates in general on what's going to be in 4.0, then yes. They update the News section of the Godot website pretty frequently with what they're working on. Most recently, they've shown how their changing the multiplayer networking and replacing GDNative with GDExtensions to make extending the engine easier. Several bug fixes and minor enhancements get back ported from the 4.0 branch to the 3.3.x and 3.4 branches as well
Actually, this is not the case. 4.0 has a GPU lightmapper which relies on Vulkan and compute shaders to work. 3.3 got a new CPU lightmapper that replaced the old "last minute" CPU lightmapper that was initially added in 3.0.
The new CPU lightmapper will likely be ported to 4.0 to allow baking lightmaps when Vulkan support isn't available.
UIDesignTool now support batch edit with toolbar & Vertical alignment.
Other than that, this release mainly focus on improving v0.1.0, in terms of UI, efficiency & bugfixing.
Github: https://github.com/imjp94/UIDesignTool
Godot Asset Library: https://godotengine.org/asset-library/asset/717
For more details, check out (https://github.com/imjp94/UIDesignTool/blob/master/CHANGELOG.md)
Note: Users updating from v0.1.* to v0.2.* might needs to specify font resource directory again, due to a bug which has been tackled in v0.2.0
I just thought I'd mention Godot, a free and open source engine that's been getting more and more attention recently:
​
​
It has a built in language that's similar to Python, but you can also use C# or other languages with it, if you want.
​
If you want good tutorials and assets to buy etc, probably Unity is the best for that.
​
But I enjoy Godot for its simplicity and purity - it's a very small install, everything is built in to the main editor (which itself is written in Godot), and it has a very logical and neat way of structuring games into trees with nodes.
​
I would say Godot is easier to get into, if you are ok with figuring some stuff out yourself by asking questions etc. There are tutorials available, but not as much or as good as the big commercial engines.
This. Godot Engine 4 has a similar thing going on too: https://godotengine.org/article/godot-40-gets-sdf-based-real-time-global-illumination
SDF have taken over the industry lately and I love it. Ever since seeing them in the demoscene I kept wondering how long it'd take before they went full mainstream. Glad to see it's happening in a larger scale than expected (for example, here's a small indie project using the same tech for animating icons in UE4)
Valve bought out the MoltenVK folks to open-source it, allowing Vulkan to work on OSX without having to pay a fee. This was the reason the Godot engine recently announced they would be concentrating almost entirely on Vulkan for future releases.
So thanks to Valve, Vulkan is now truly cross-platform. :D
Have you tried Godot?
> Today we are releasing the first beta version of Python for Godot, the GDNative interface that enables you to use the full-blown Python 3 as a scripting language for Godot games.
Posted on 2017-07-12
No, Godot is licensed under the MIT License, which is not a copyleft license like the GPL. The license grants you:
- You are free to use Godot Engine, for any purpose
- You can study how Godot Engine works and change it
- You can distribute unmodified and changed versions of Godot Engine, even commercially and under a different license (including proprietary)
https://godotengine.org/license
You need to include the copyright notice and license statement of Godot Engine however. The website states further:
> "Godot Engine's license terms and copyright do not apply to the content you create with it; you are free to license your games how you see best fit, and will be their sole copyright owner(s).
> Note however that the Godot Engine binary that you would distribute with your game is a copy of the "Software" as defined in the license, and you are therefore required to include the copyright notice and license statement somewhere in your documentation.
> The Godot Engine developers consider that a link to this page (godotengine.org/license) in your game documentation or credits would be an acceptable way to satisfy the license terms."
https://godotengine.org/showcase
I'm not familar with any of these games outside of my familiarity with the Godot Community. The engine is still relatively new. And when it was brand new, it wasn't a viable option for a lot of people. In the years since it has become more feature rich and thus more viable.
All that to say: Not yet, but we're getting there.
Godot has a web-based version in beta now. I checked it out, and it seems to work like the desktop version.
His story seems to be almost the universal story. When it's easy to support Linux, we get Linux support. When it isn't easy to support Linux, we don't get support. The sales aren't worth it unless porting to Linux is effectively an extra few button clicks and maybe a handful of bugs.
This is why we also get more indie games than AAA games, AAA publishers are driven by investors to achieve maximum return on investment. Which means it isn't strictly a matter of if something is profitable or not, it's a question of "what's the most profitable thing we can be doing right?".
The take home from this is, if we want more games on Linux, we need to make it easier for developers to support Linux. That means we need more engines and middleware to have out of the box support for Linux (long term, supporting Godot is a good idea), and we need the Linux ecosystem to be as easy to develop for as possible. Expecting developers to come to us isn't going to work, we need to make it easier for developers to come to us.
That's partly why Valve's Proton project is such a good thing, because it reduces the effort for developers down to zero.
Well, there is already showcase of games on godot website (https://godotengine.org/showcase) but it could be more detailed. Also for a while there is the same game on front and I don't know if there is no new games or it isn't updated. I think the best thing would be list of games with "recommended" or something section.
Have no fear, the tilemap editor is getting overhauled in godot 4. Someone has also made a plugin for Tiled that exports (and imports) godot tilemaps.
The flexible simplicity of the scene system is one of my favorite aspects of the engine as well. It makes it so easy to compartmentalize development.
Godot is the first game engine where I don't find myself wanting to turn into a Game Framework Architect and instead just make my game. I don't know what it is about Unity and Unreal but every time I try to make a game with them I find myself making a new framework to fight their "design".
I recommend reading this blog to understand why Godot is the way it is https://godotengine.org/article/how-actually-make-your-dream-game
But the bigger picture is Godot will probably never match feature for feature unity or unreal. They have massive highly paid dev teams. Unity has raised over $100 million in the past couple of years. But in my case and in most indies cases you will never get around to actually using those features. You just think you will, but you won't in the end.
Given credit when credit is due and respecting licenses has nothing to do with an engine. The Godot engine is MIT licensed. It means you can do anything you want with it, but you have to include the license somewhere. https://godotengine.org/license
The area owners for the code are not announced yet but If you're serious about paying for the fix you can probably contact Rémi Verschelde (the emails are here https://godotengine.org/governance ) or state it in the relevant github issue.
Autodesk don't bother sueing people with that, as pointed out by Ton Roosendaal, they favor the abuse of proprietary format and break it every years a bit to fuck with people reverse engineering it.
And that's my whole problem with that and people that keep requesting it:
- it's a format that have people bound to it,
- if you try to use FLOSS (be it Blender, or Godot in the near future) you'll more often than not lag behind and the versioning of the format is batshit crazy.
- It has into the Front / Up axis problem on the importer (that reduz wrote about on why Colladea failed / why glTF2.0 should be used)
- it has pretty much no documentation available that actually define what's standard in it.
It's a de facto standard, but it's anything but good for anything else than Autodesk.
^ This.
I initiated this fork in 2016 to keep an archive of the last GPL commit for software preservation, and for easy access for potential new maintainers that would bring it further while reinforcing its GPL nature by lack of a CLA. Nobody showed up (which is not surprising as Aseprite had virtually no code contributors due to its CLA).
Now I was strongly encouraged to finally rename the fork to avoid confusion, and news about it is behind shared on several platforms... I don't mind either way, let's see if some motivated devs show up, but on my end things haven't changed (actually things did change, I maintain Godot Engine and definitely don't have time to maintain another piece of software, even if LibreSprite is much simpler than a game engine).
So... let's see what happens. But it's not breaking news, and this fork is already two years behind the proprietary Aseprite as it saw no development work since 2016.
Okay, this has some problems.
It fails - completely - to mention the fail faster principle.
You do not want to commit to making art before coding the gameplay.
It's a bad, bad idea. A waste of resources and time.
If the core gameplay works, it works also with a rectangle shooting squares and dodging differently-colored rectangles. Gameplay should come before making art assets - it's best to use generic ones, since your concept may prove completely unsalvageable, or require big, sweeping changes to its mechanics. And you'll know it only after you've coded it and let some other people playtest it.
And in the Code part, too:
>(All code examples here are in C++, one of the main languages the Unity 3D game development framework uses.)
...Unity game logic uses C# exclusively.
Finally, in game development, object oriented design is a crutch, not an "important game programming concept". Data Oriented Design is. Here's an example, in Unity: https://www.youtube.com/watch?v=_U9wRgQyy6s
And failing to mention Godot Engine is absolutely barbaric.
For an open source alternative, Godot is shaping up real nice. It takes some great ideas from many other engines, contains zero assets so it's a tiny download, extremely permissive license, great community and support, easily extendable; as the editor is the game engine so you can script it the same way. I just really fell in love with it.
This is amazing! I have still not managed to get Bitmap fonts to work in Godot. This looks infinitely easier and like a workflow I would actually enjoy!
Thank you so much!
Please also consider to add this to the Asset Library if you have not already, so more people can find it organically.
C++ is a worthwhile language to learn whether you want to get into game dev or not, and you should learn it.
But while you're doing that, why not get a jump on the game dev part and try out a game engine like Godot. It's free, open-source, and cross platform. You'll primarily be programming with GDScript.
GDScript should be pretty familiar if you have some python experience. That means you could be creating games faster. Godot also supports C++ for when you really need the performance.
You can use Godot and it's very python-like scripting language, GdScript, to make very powerful games.
If your game doesn't need to be very graphically intense in a beautiful 3D world making all the use of a good graphics card, then it's perfectly possible to make a nice game with it, and in some ways getting the game logic can be a lot easier.
If Python's what you know then it makes sense- it's a nice language and for smaller games (or those it's suited for) it's great.
There're a lot of Python GUI libraries out there though so do a bit of research before you choose one and spend a few days trying some of them out with test projects. Remember there're also things like PyGame and PySDL2 which may fill the gap depending on what you need. You may also want to look at Godot 3 which has Python bindings, although it may feel as alien as the other engines.
Du könntest ein Kommandozeilenprogramm schreiben.
ZB. einen Taschenrechner, der die Eingabe zerlegt, ausrechnen und das Ergebnis ausgibt. Oder die Buchstaben der Eingabe in umgekehrter Reihenfolge wieder ausgibt. Das Problem ist, daß solche Projekte wenig "aufregend" sind und Anfänger schnell die Lust verlieren oder bei einem Problem schnell aufgeben.
Darum empfehle ich dir Godot anzuschauen. Das ist eine Spieleengine die gut zugänglich ist und die eigene Scriptsprache GDScript ist Python sehr ähnlich, du solltest also deine gelernten Grundlagen gut einsetzen können.
Hier kannst du dich kreativ austoben und siehst schneller Ergebnisse.
Could you release the script on the asset library so that others can benefit from it? That would be useful as a stop-gap until built-in portal/room occlusion culling is merged sometime in a future 3.x release.
Note that portal/room occlusion culling is a different, more lightweight approach than the one merged in 4.0 which requires less manual work.
Ha, that was honest :-)
This was just announced - did you try version 3.2 ? If not, then it would be great to read a comparison. https://godotengine.org/article/major-update-for-visual-shader-in-godot-3-2
They're adding a Vulkan renderer backend to the engine as another option to openGL. Here's an article on the Godot blog talking about it: https://godotengine.org/article/abandoning-gles3-vulkan-and-gles2
Godot 3.0 is quite around the corner and since beta builds are very stable I can recommend to get get latest beta build here: http://godot3builds.digitecnology.com/
Documentation for 2D in 3.0 should be somewhere 90% completed (which covers 100% of the most used stuff) and 3D documentation is 70% complete (which covers like 95% of most commonly used stuff). In short you are not likely to problems with 2D docs, if that's you are interested in. Latest (for 3.0) docs can be found here: http://docs.godotengine.org/en/latest/
Community is smaller than in Unity, but very welcoming and quite active. I can highly suggest to join discord. Right now it has about 1000+ users active. Invite to Discord and other social links can be found here: https://godotengine.org/community
I don't know Unity really well, so I can't really say which one has the most features, but Godot has more than enough of them, at least for me.
It is lightweight (50 MB without export templates) and it is, you know, free and no strings attached, so nothing is stopping you to check it out right now.
I think if you're REALLY concerned about pricing issues, you should just go with Godot Engine (cause it's completely free and open source). However, I also agree with others here that 1) UE4 really sucks for 2D development (Unity is WAY better) and 2) you really shouldn't bother worrying too much about the money side of things for your first couple of games (which I assume this would be considering that you only have "some experience" with Unity).
Personally, I prefer Godot Engine for 2D stuff cause it's really easy to use and organize, but Unity has more built in tools and publishing platforms so it is also a good option.
It’s 100% doable, but it would require you to use JavaScript extensively. If you want to make a web game, and don’t come from a programming background, then you could just use Godot (https://godotengine.org/). It’s free, open-source, and you can get it on Steam so that it autoupdates. It can also export web games. It does use a Python-like scripting language, but you’ll be able to figure it out if you read the guides and play around with it. Feel free to DM me any programming-related questions you might have.
I'd recommend Godot. GDScript is Python-like (pythonesque?), the engine is free and open source, documentation is decent, it's fast and fun to work with, its 2D is stellar, and its 3D is more than a match for any top-down Pokémon-style game.
One thing I recommend. Please put the final product on https://godotengine.org/asset-library/asset That way people can just start with a doom template as well and go through your tutorial to get the bits they need when they want to modify it. Or someone like me who has a lot of UE4 experience would love something like this as a template over a tutorial to get started right away.
Title is bit misleading, C# exporter only works for exporting to Windows, Linux, and MacOSX. No mobiles yet :(
Also, why this issue hasn't been fixed?
https://godotengine.org/article/fixing-godot-games-published-google-play
It means that if you make Android game in Godot, it can be removed from Google Play! Apparently you need to use fixer tool:
https://godotengine.org/article/godot-apk-fixer-tool
Currently, Android export is pretty much a hack:
https://github.com/godotengine/godot/issues/18865
I love FOSS projects and i'm really counting on Godot to become Unity alternative for mobile gamedevs. But this issue with android exporting is really big IMHO. I think that for now, Android export should be marked as experimental / beta, until it's rewritten.
The video didn't mention SDFGI, which is pretty new and seems to be the closest thing to GI without any raytracing.
First, it would be best to properly learn programming in general before jumping right into Godot.
For input in general, you can look here:
http://docs.godotengine.org/en/3.0/tutorials/inputs/inputevent.html
You can look for tutorials of different systems in the docs, but keep in mind that not everything has those. For further and more specific information you can look at the actual documentation of different nodes and methods.
You can also just look for information on google, if it's a general problem/need you would have no problem finding results.
There's also a few demos on the official site, giving examples of implementation for popular needs.
https://godotengine.org/asset-library/asset?category=10&support[official]=1
And last but not least, check out the asset library, which might be able to save you time considering you're less technically proficient.
If you really care about native Linux support the best option is Godot. It's perfect for what you describe. It's the easiest to use (yet powerful enough for commercial games of any kind, it's not a toy), and is the only mainstream game engine where Linux is a first-class citizen.
Also keep an eye out for Bevy in the future if you ever need a powerful data-driven game engine. It's still young but shows great promise.
Ignore news of "open-sourced" big corporate engines (like recent O3DE) unless there's clear indication of a community forming up. They may end up abandoned like so many other code-dumps that happened before.
>Godot, piu' facile da usare a mio avviso, meno potente ma anche meno buggato. Non ci sono tutorial fighi, ma ci sono tutorial ed e' documentato bene
Ma quando compili tocca aspettare, e aspettare...
Instead of buying GameMaker Studio I would recommend you to try Godot Engine https://godotengine.org/ After many years of using GM:S I just can't handle all the flaws it has, Godot is so much better and Open Source. So yeah :)
I would definitely go with 3. There are a lot of neat new features in the pipeline.
As for differences between 2, take a look at the 3.0 release blog https://godotengine.org/article/godot-3-0-released
At this point I don't know if there's a good reason to start a new project in Godot 2. They still support it but I think the bulk of new features and improvements are going to be for 3.
Unity has tutorials, some of which assume no game design experience. Unity uses C#, which is the language being used in the beta version of the Godot Engine (3.0). You can also subscribe to different subreddits (for example, /r/godot). I tend to hang out in PlayDungeonmans Twitch streams when I code.
In general, once you've picked a starting point, you just have to dive in. If you can afford it/spare the time, take a couple coding classes at Community College or a tech school. Give yourself goals with deadlines and follow them.
Most importantly, have fun!
In Godot 3.0 this is no longer the case thanks to the introduction of GDNative, which allows you to use code written in any language in Godot without having to recompile the engine. You can read all about it here. But be warned, it's still a brand new feature and documentation is lacking, so you'll have to do some research on your own.
Godot deserves a mention.
I do not believe that engines are lacking, but games are. I agree that the main problem is content/assets. A game requires a lot and it should have the same style throughout.
Just download it from the site. Steam has 500mb worth of demos included that you don't need. I don't know what you think you're getting from compiling yourself unless you just want to be a l33t h4ckor. A rare few plug-ins will require compiling but the new system avoids that even. https://godotengine.org/download/linux
>"GDot"
I know Godot is tricky to pronounce for some, but I did not think it would be so hard to spell.
Someone please comment on their twitter and pass on a link to https://godotengine.org so people reading their tweet can find it more easily.
The documentation on this is here: https://docs.godotengine.org/en/latest/tutorials/performance/using_servers.html
And there are a few project examples in assetlib too, specifically the '2D Bullet Shower Demo'.
Still learning Godot and wanted to check out the voxel plug-in by ClarkThyLord. It's really cool! If you're interested in the source of my castle builder you can grab it here, feel free to ask anything about the development.
The Godot editor use TextEdit for input and syntax highlighting. Take the text and follow this to execute the GDScript. If you need another language then you gotta roll your own.
Engine: <strong>Godot</strong>
Game's github repo: <strong>https://github.com/PonasKovas/emberhunt</strong>
We will happily welcome everyone who wants to contribute
No, you don't have to do any of that. The only restriction is that you have to distribute the copyright notice and license statement of Godot Engine when you redistribute it, for example in the documentation or the credits.
For more details I recommend https://godotengine.org/license.
If you're not interested in programming at all, I would recommend Clikcteam Fusion. Here's a video series someone made about the games he made with it.
Alternatively, there is also the free GDevelop, which also doesn't require programming.
If you are interested in programming, the free and open-source Godot engine would be ideal. :)
There's Godot, which doesn't really use Python, but their custom language is heavily influenced by Python. However, there aren't really any good 3D engines using Python itself.
If you're just learning though, it's important to learn the concepts, which you can do in any high-level language, really. If you're familiar with how programming works in general, you can translate that knowledge to a new language just by learning its syntax.
Besides being free and open source and full-featured, the community is quite active and helpful. There is Godot Q & A which is pretty much like Unity Answers, as well as /r/godot, and people are quite helpful on both.
Have you already tried the LOD add-on from the asset library? https://godotengine.org/asset-library/asset/729
If you want to create your own implementation, that add-on might still be a good guidline for godot 3.x
In Godot 4, LOD will be available in the engine, so you could also try it out in v4 with the native implementation (not sure how functional that currently is)
I'm not claiming to be an expert, but I think I can explain the difference fairly accurately.
Both systems have a World, with Entities, and these Entities contain Components.
In an EC engine, like Unity (normal Unity, not their DOTS ecs), these components are classes, and they have functions that are called on component creation, frame update, etc.
With an ECS, components are just data, and you have a separate concept of systems for running the actual code.
The advantage of an ECS is that your components are just plain data, and this allows a ton of memory/cache locality optimizations among other optimizations, but it also easily facilitates building up complex interactions, because systems are decoupled from a specific component, meaning that systems can only apply to entities that have a specific set of components, and so forth.
Basically, ECS is better for things like simulations, games where CPU performance is critical, and games with a lot of emergent behavior.
The downside to ECS is primarily the cognitive load. Some people really mesh with the ECS way of doing things, but there is an extra level of indirection that you have to grasp when working with the paradigm that you don't have with EC engines, where you can just create a component and define its behavior right in one neat place.
They both have their pros and cons, and they both have valid uses.
If you want to check out some examples of these in action, Unity (proprietary) supports both EC and ECS (via their official DOTS plugins), Godot (MIT) supports a modified EC (only one component per entity), and Bevy (MIT) has the best ECS I've come across, but it's written in Rust, and is pretty early in development still.
Check out Godot's page on their license. Fortunately for you Godot uses the MIT license which lets you do basically anything you want so long as you include their copyright notice somewhere in your project.
Other open source licenses aren't so lenient. If you really intend to sell software you must understand the licenses of the parts you use, in particular licenses like GPL obligate you to produce source upon request and other restrictions.
I think the first thing I need to interject here is that a language is only as powerful as the way that the programmer uses it. C++ (since it's been brought up) won't stop you from writing horrifying code, if you don't know it really well. Additionally, the majority of the advantages that C++'s few edges, like low level pointer math, will give you are typically taken care of in the rendering engine already.
That said, it's more a question of what you're comfortable with. Godot's language-agnosticism and expansibility is something I've always kind of admired about it; but you still need to ask yourself, is your team capable of understanding it? Is there a better alternative to it, which you are comfortable using? Are you comfotable/uncomfortable with duck typing? Is there anything just plain weird about the language that will be a problem, however minor, with the GDNative interface?
Godot has basically promised that GDScript (which is damned near Python, but not quite) will always be their language of choice, but they like flexibility. The support for C# is generally because of demand, both from users who may also have a measure of familiarity with Unity (which uses C# by default), and from companies who may already have an established C# workspace.
They cover it in detail here.
> Also a better way to prototype quick layouts as the basic meshes don't have hitboxes. I'd like some basic boxes with a texture that shows scale even when stretched and skewed. IIRC Unreal has textures like that.
Godot 3.1's new CSG nodes will help take care of that for ya! :-D
Interesting, it appears to be a new format from khronos being used called glTF 2.0. Seems to be even better than FBX for video game assets according to article. (Would still prefer to also see FBX though)
Here's a nice blog article:
- How to make your dream game, publish it and not die in the process by Juan Linietsky Aug 11, 2017, godotengine.org
There's a guy (Emmanuel Leblond ) trying to bring python into Godot. I think it's in beta state at the moment. You can read more about it here: https://godotengine.org/article/beta-release-python-support
Beginners only need to care about what https://godotengine.org/download points to.
Or refer to the linked release policy to understand what the various versions mean: https://docs.godotengine.org/en/stable/about/release_policy.html
I didn't have a lot of time, so I just swapped the gameplay scenes of my PitchYaGame trailer with scenes from the current version ( You can play the rather long demo on Steam if you like .. a lot of things were updated! ).
If you want to submit your game, head over to the Godot Website and read the following post - And by the way, there are also some useful tips here.
Good luck everyone! 😁
Godot is a game engine where people could edit the base game from! it's also easy to learn, so as long as someone makes with with expansions and modding in mind, that'll be a cool place to build
First, be very, very sure you want to make games. It's a difficult industry to work in.
Second, there's no reason you couldn't make an open source game. As long as you have a good idea you can put whatever license you want on the code.
Finally, there's already a lot of open source game engines like Godot, so if you want to start making an open source game you already have the tools.
Forward rendering is also useful for non-mobile low-latency situations like VR.
Combined with fancier approaches to forward rendering like Clustered Forward (for example in DOOM or Godot), vanilla deferred rendering is not necessarily the default everywhere.
While those fancy approaches aren't necessarily any easier to implement than deferred, you may want to consider them depending on what styles you're going for.
Godot is going to be your best bet.
Doesn't use Lua out of the box, but it does use two languages you can pick from (GDscript, which is similiar to python, and C#)
Someone has also written in 3rd party Lua support for it if you absolutely must have Lua.
Personally, I'd recommend the Godot engine. It's 100% free, open-source, supports a wide variety of platforms (including Linux), has an extremely nice editor that's intuitive and easy to use, and now has a decent amount of free tutorials online to help with getting started. It also supports a number of languages, such C++, C#, Python, and it's own Python-like language called GDscript, which integrates very nicely with the engine.
Here's a nice indepth article comparing Godot to the other major engines, like Unity and Unreal.
Anti-alias those lines ! it's the first thing people see when they click the link and it could look a bit smoother.
Agreed - I think you should be using an existing engine. I would add Godot to your list, as the 'up and coming' engine. It supports GDscript (syntax similar to Python), C#, a Visual Scripting language and C++, but don't know how full the support is for the visual scripting language and C++.
Also for Unreal Engine, you can make games entirely with Blueprints (their visual programming language).
The official asset library has no plans to offer paid assets, for legal and ethical reasons – the Software Freedom Conservancy handles the funds of Godot and would probably not be able to handle this as a nonprofit, and paid assets are often distributed under a proprietary license.
Great article and finally a "hub" place to look for knowledge and tutorials!
Do you know Godot Engine? It's both powerful and very beginner friendly, as GDScript is a robust but easy to use language (resembles python a lot). On top it's open source and free to use :)
See https://godotengine.org/qa/4018/does-godot-have-plans-support-exporting-consoles-ps4-xbox-etc
PS4 definitely exists since Deponia was ported for the PS4 using Godot (yes, the desktop versions of Deponia use another engine, but the iOS and PS4 versions use Godot). All console publishers put their SDKs under very restrictive NDAs, so it's not possible to make those ports open source, hence the lack of interest in them overall as it's not particularly interesting to work on ports that you can't make public.
If you are licensed for some consoles, contact punto to discuss what you could have access to.
Visual shaders are getting a lot of improvements for Godot 4.0: https://godotengine.org/article/improvements-shaders-visual-shaders-godot-4
Visual scripting won't change as much because it doesn't have as many active contributors.
I think you'd have a good time with Godot. While not necessarily being different, it avoids expensive licenses because it's FOSS (Free and Open Source Software). They have their own scripting language GDScript or you could download their Mono version and use C# instead. While being low on tutorials currently, the content of those tutorials are really good. Garbaj's Tutorial Playlist and GDQuest's content are good material to watch for learning Godot. Also, they just released an M1 native version of Godot Mono.
There's a short article here about transforming signals to callables.
The idea is that you can now specify exactly the function to call, instead of using the brittle system of writing the function's name in a string. This removes a huge possibility for bugs, and the editor can now auto-complete it for you.
It's like a functionref but the editor handles it for you. You don't have to explicitly create it or free it.
I'm going to make a post soon about how I updated my game-jam game from Godot 3 to Godot 4, where I mention everything that I had to update. It should help understand the changes required.
Nice work! That video series by Heartbeast is excellent. Bookmarked your repo to give it a closer look later.
Interested to see how the GDExtension in Godot 4 ends up working in practice.
It's based on this demo! The game is rendered three times, with strong dithering, mild dithering, and no dithering. The dark dithering is rendered by default but lights are used to reveal the versions with mild or no dithering on top of it. Hope this makes sense!
Figured it out on my own, just wanna leave it here for future strugglers:
Apparently, according to this article, the mouse wheels only gives a just_released action and no pressed actions.
This means only Input.is_action_just_pressed("scroll_up_or_down_or_something") works. is_action_just_pressed and is_action_pressed will not work for scroll wheels.
There's a 3.x branch on github, there also is this in the new release policy:
https://docs.godotengine.org/en/3.3/about/release_policy.html
Godot 3.4
Q2 or Q3 2021
supported Beta. Receives new features as well as bug fixes while under development.
And in the blog post:
https://godotengine.org/article/godot-3-3-has-arrived
So we've reopened a development branch for 3.x releases, 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).
Since release policy has changed and there's really mostly info about 4.0 I'm lookin for info about the 3.4 now :-).
Btw 4.0 release is expected to abou about 2022 first half.
https://godotengine.org/article/camille-mohr-daurat-hired-work-physics
"And not just that, but Godot 4 improvements around GDNative will allow
different physics engines to be easily integrated as plugins. This opens
the possibility for Nvidia PhysX to be supported in the future."
Engine: <strong>Godot</strong>
Game's github repo: <strong>https://github.com/PonasKovas/emberhunt</strong>
We will happily welcome everyone who wants to contribute
I believe the godot lead dev is from Argentina. They also already have a Patreon with contributions of about 10 000$ per month.
If I understand this correctly, there are at least one or two people working on Godot fulltime.
Perhaps you mean with something like Godot 3.1's new CSG nodes? Or maybe with /u/mux213's Houdini-like procedural mesh generation plugin?
First of all, while karroffel mentioned me and other contributors in the previous report, I think it is fair to say that he is doing this all by himself, so if you can and want to help, I am sure he would appreciate it.
I do follow the IRC logs and I occasionally track his repository, and here is my take on the status of GLES2, especially from the point of view of my branch (3.0-gles2: https://github.com/efornara/godot/blob/3.0-gles2/GLES2.md ).
Both master and 3.0-gles2 are using a previous version (2D-only with some limitations, see below), so if you want to test the new features you have to compile his branch yourself. IIRC from the logs, the idea is to do another merge into master once PBR and lighting is useable. My guess (and I might be way off) is in 2-4 weeks.
Regarding 2D, in the current master/3.0-gles2 branches (2D-only), as far as I can see there are only three main limitations: no particles, no custom shaders and no (2D) lights.
Particles are not mentioned in the report, but they are tricky and probably a somehow lower priority. So, if you want particles anytime soon, you are better off using https://godotengine.org/asset-library/asset/189 . I haven't tried it, but my understanding is that you can use it on GLES3 to "bake" particle effects into a sprite and use that sprite in your GLES2 build of the game.
For custom shaders, the new developments might help. I tried a version a while ago and I had some issues, but I saw some commits recently that might have addressed them.
I assume 2D lights are not there yet.
It looks like 3.0.3-stable might be out in 2-3 weeks (again, only my guess). My current plan is to then release 3.0.3-gles2-v1 with the same limitations as 3.0.2-gles2-v1 regarding GLES2 support, and, if it looks useable/stable enough, 3.0.3-gles2-v2 soon afterwards with some more features (e.g. custom shaders, but still no 3D).
I could never stick with PyGame long enough to finish a project - so I'm not much help on that front regarding exporting to different platforms.
I highly recommend checking out Godot. It's what I'm currently using and GD Script isn't too different from Python.
It supports exporting to all major platforms and exporting my game with touch support to Android was pretty easy.
What about Godot?
Personally, I only had a quick look once but given that there are commercial games using it and the recent buzz esp about the upcoming version 3 which is in beta atm it feels quite strange that it is not mentioned. Any particular reasons?
We've been using October for the Godot Engine website since early 2016 and it works pretty well for us. It is not as easy to use as WordPress, but definitely feels more flexible.
It's certainly different from Unity, but I wouldn't say it'd be too difficult to switch over. If you mainly develop in 2D, I think you may find Godot to be easier to work with overall.
As for the community, Godot has quite a number of different places to ask for help, including r/Godot. But the best place would likely be the superb Q&A page.
There's also now some really great free tutorials available on youtube from people like GDQuest.
Hope that helps. ^_^
Just to add a little to other comment:
https://godotengine.org/ is freedom free and the next release (end of year est) will have the PBR shaders that UE4 and other recent engines have, sometime after that it will get the visual code like UE4 has.
UE4 is on github, though it's not freedom free. If you want to make a free game with it, the license cost is revenue based so that's a non-issue. If you want to make a fully free game, use godot or one of the other appropriately licensed engines.
Why no AAA free games? Most such things take 100+ talented people working full time for 3+ years.
This was added in 3.4 here is the blog post which gives the full description:
https://godotengine.org/article/godot-3-4-is-released
TL;DR
Key W = W Always no matter the keyboard layout
Physical Key W = W on QWERTY Layout(American), but Z on AZERTY Layout(French)
One is Layout Dependent, where the other is Layout Independent.
This allows you to for example, always have the same Physical Location for WASD movement regardless of Keyboard Layout.
Most languages call this operation map. I don't think gdscript has this built-in, but you might be able to implement this yourself by using a FuncRef, although you won't be able to declare the function inline like that because gdscript currently doesn't support lambdas.
Lambdas are coming in godot 4, and I think I read that map is coming as well. So you could also just wait.