++ Open License and friendly community.
++ The scene graph (node tree / prefabs) is well done, better than Unity. You can easily switch between scenes (Prefabs) through tabs and convert subtrees to separate scenes. Nesting scenes works really well.
++ The inbuilt scripting documentation is great.
- C# is not fully there, yet. No Visual studio integration. Debugging through VSCode is a pain. WebAssembly Exports are not optimized yet. That's why I sticked with GDScript.
+ GDScript is a nice language with optional type hinting. But refactoring can mostly be done through search/replace.
++ Windows and HTML/WebGL exports are super fast. I did not have problems since the RC.
- The inbuilt editor for GDScripts is ok. But I'm missing my VIM shortcuts...
- Arrays, dictionaries are not generic. Enums are not typesafe either. Bit me a few times.
- You cannot inspect the scene in the editor visually while debugging. This is what I miss the most coming from unity. Some things are really hard to debug this way, for example if you use procedural generation.
- 2D coords starting at the top left corner of the screen and increasing right/down is really confusing. If the player jumps, y goes down. It's a bit strange.
- I'm a bit afraid regarding the +5000 open issues on github. I wonder, how they will handle that in the future...
Most content creation software that I've used are right-handed with Z-up, maybe dating back to CAD packages treating floor plans (or other 2D drawings) as XY? Maya is an exception here with a Y-up, and I think SolidWorks might be in that camp as well.
2D coordinate systems almost always have top left as (0,0).
3D has not had the benefit of an obvious hardware model to emulate. Y-up, Z-up, Y-down are probably the three most common variants though.
I haven't seen Y-down (in 3D space) since software rendering days.
I've yet to meet the monster who would use X-left. :P
It's all arbitrary anyway, so why not let one thing be consistent instead of saying "Y is down on the screen, but in the world Y is sideways and Z is up."
(I do still think it's weird, but I'm sure I'd get used to it)
I'm not sure where the convention comes from. Maybe CRT screens drawing that way?
Does this include looking at the [Server] tab in the editor once the game is running? That shows dynamically created nodes at run-time.
Thanks! Learned something new!
Someone on reddit showed me this same tip.
You can even change values on the remote tab and have them reflected live in your game, which is fun for prototyping.
> The current implementation of the text field looked pretty much straight forward and exchangeable. So at anyone reading this, feel encouraged to grab this issue! :-)
> You cannot inspect the scene in the editor visually while debugging.
This video (https://www.youtube.com/watch?v=HuTKFha8QBs) shows how you can override the running game with what is in the scene view.
The reasons seem historic: https://gamedev.stackexchange.com/questions/83570/why-is-the...
Where do the coords start in Unity? Just curious
In Godot it's reversed, I guess because screen updates usually start at the top left corner of the screen.
Agreed about 2D being from top left. Makes sense in theory, feels unnatural in practice.
Edit: I believe also Scirra Construct uses the same.
They mentioned in the article, that they closed 2000 issues for 3.2 and that's quite an achievement. I simpy hope, that the main maintainers can handle the load. Triage new issues and managing open ones is draining and not a fun task.
I mean to look into the list, maybe find some low hanging fruit, but it costs so much time if you ain't familiar with the engine. Time which could be used to write games... :)
Recently I tried Godot because I was looking for something simple I could teach to kids, and I was amazed how easy it makes game creation. I made these games with no experience in just a couple of days!
GDscript is great. It's similar enough to Python that kids who know Python won't notice much difference, and it actually simplifies things for beginners, e.g. you can use objects without the need to define classes because they are created automatically when you create a script.
Godot is still a little rough around the edges, e.g. not everything has keyboard shortcuts, sometimes it crashes, some of the built in tools like map editor are very fiddly to use. But it's open source so I'm sure they will be fixed eventually (and if they aren't I can always do it myself.) The only major issue I can see for the future of Godot is the lack of exporters for Xbox, Playstation and Switch.
EDIT: This page has some backstory: https://docs.godotengine.org/en/3.0/tutorials/platform/conso...
But there is another open source game library, Monogame, that distributes their code for free for consoles. You just have to vertify that you are have signed the NDA before you get access to the code. They advertise this. So there is no reason that Godot couldn't do the same if they wanted to open that code.
Putting that aside: developers who do this kind of (difficult, tedious and thankless) work are entitled to ask compensation for their effort, on top of everything else they do for free.
(I'm not affiliated with Godot, I just use it and love it)
George however, who has been employed only recently does live in Brazil (according to his GitHub).
After Epic originally promised to make linux a first class citizen, I went all in ue4, but they lied and went back on all those promises, and I have since moved to a completely open source gamedev pipeline and I think it's the future.
For example, think about how much mods make or break game longetivity and communities. If valve hadnt given us world hammer, there would be no counterstrike, no tf2, no garrys mod, no age of chivalry and ergo no chivalry medieval warfare. The residual effects of modding capabilities are huge, and having formats that are easy to work with with normal tooling (like gltf) mean open source gaming in a game engine like godot (or a few others, armory3d is another) could be a sleeping giant just in the early stages of waking.
Obviously having full game engines available for free has pretty much usurped modding's place in the games industry but they're still cool and you still get new games based on mods (PUBG is a recent example)
I am also thinking hard right now about what kind of business model could fit best for foss gaming. That's a whole other conversation though I guess.
To be clear, I was talking about two things, linux as a target client platform, and linux as a dev platform.
While it's great that you could move away from it, a lot of in-development games are already stuck with UE, and it's a concern if they won't be able to make well performing Linux releases.
To be fair though, in anything where minimal latency is important, the networking comms should probably be done outside the game engine, but I think just doing protyping with the networking api and then seeing if that is needed would be the way to go so you don't create work that isn't needed.
But which engine... that's an open question, and I'm not that fond of Unity :)
If you're looking at the Quest, Holger Dammertz is doing an awesome job with the Oculus Quest Toolkit where I'm also a contributor.
...still hacking around with Unity, but after I get a basic PoC of what I'm doing I might switch to Godot (with C# as the language) for developing the actual MVC.
I'm pulling in desktop screens to VR which can be moved and placed as wanted. Working on pulling in individual applications and doing application launching. Aside from that it exposes a good bit of file system access in game. So a decent amount of stuff a productivity app may want to do.
I'm not a Unity guy but I briefly tried VR in Unity and the support seemed quite fractured. SteamVR has multiple versions across stores/github and I wasn't sure which to use, ditto for various tool kits. Godot I just downloaded a sample project and striped it down then worked off that.
The hardest part is doing anything non-gamey. Occasionally I'll make a help post and people will just reply "why would anyone want to do that?" but the C# support means you can use just about any libraries out there, so pretty much anything is possible with enough fiddling. I dropped the idea but even had OpenCV working with the Index's webcams at one point.
Once you get it all set up, you can just hit the android button and it’ll export the apk directly to the device. Also, you are still able to live view via wifi.
It's not the API itself, but juggling all the different coordinate systems (room, eyes, controllers etc.) that tends to keep things interesting.
It also seems to support c++ as "gdnative", although it requires another compiler to link against godot's binaries. It seems awkward because you still need to use the godot editor, and there is still a lot of interfacing to write.
It seems like a good alternative to unity, but in the end, all I want is an engine, not a "framework" or some awkward scene editor with some kind of Node hierarchy/interface.
I could say the same thing about UE4. I hear everywhere that's it's the place to go, that "everybody uses it and it's the norm in the industry if you want to make a game from scratch", but the reality is that those frameworks are too big and too feature rich. It sounds like they want to attract young developers to lock them into those awkward frameworks, because they advertise it as being full-featured engines, but small developers might not really need to focus on bleeding edge rendering, so it doesn't make sense.
I know there are engines like Ogre3D, but I would rather spend time learning an actual universal graphics API that works on all hardware, which has more value on a resume, and I can just use what I need. All other things like audio, animation, inputs, physics, etc are available as C++ libraries.
Those frameworks are saying "see? you can make your own game with those tools!", but when you actually learn how a computer works, and know how to write code, you realize you want to avoid those frameworks because they conceal too much from the programmer, and usually you don't want a developer to not understand what the framework is doing. I guess this is why people have a problem with certain object-oriented practices and abstraction.
Here is a nice video which benchmarks unity against a simple, very similar from-scratch equivalent. https://www.youtube.com/watch?v=tInaI3pU19Y
But I love Godot. I struggled with it too, at first, but probably around hour 6 of messing around, it all just clicked: Godot is actually a visual abstraction of object oriented programming. You get to write and extend visual classes, then instantiate them in scenes.
Once it clicked, I realized this is exactly what I wanted. An engine that knows how to do physics, 2d, 3d, etc, and gives me very fine grained control over how objects in this universe behave (basically, anything you can code, you can attach to a node).
So based on what you wrote above, I think you would actually like Godot. There is a steep learning cliff, but once you get past that Godot lives at just the right level of abstraction. Doesn't do too much, but does the stuff you shouldn't have to worry about.
Using game engines may not suffice to your use case, but for a lot of people that's the best way to develop games. This argument is similar to using a systems level language vs a higher level language.
I myself prefer game frameworks over either raw graphics APIs and game engines, since it provides me with my preferred level of control while meeting my particular needs. I can see where you come from, if your goal is to learn and highlight that in your resume, writing and experimenting against the graphics APIs are likely the best bet. But for a lot of people, their main goal differs from yours, which is to... make a game.
Here is a good video about benchmarking unity https://www.youtube.com/watch?v=tInaI3pU19Y
It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy.
With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment.
So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.
Good luck with that, no, game consoles don't do GL, most Switch games use NVN and it remains to be seen if PS5 will have Vulkan support.
These engines and frameworks are welcomed by the industry, because in most studios game development teams, the programmers are a minority, game designers and scripters are who actually make the game.
Anyone that wants to learn how a computer works should learn Assembly and low level coding.
Get a Raspberry PI and do bare metal game coding in Assembly like we used to do in the 80's.
Unfortunately such a thing doesn't exist. You either have to choose something that hides the graphics API or use the preferred API of the platform (Metal on iOS/Mac, DX12 on Windows, Vulkan on Linux). If you decide to use a second class API then your UX will be second class but game engines don't suffer from that because they use the platform specific APIs directly.
So the UI and everything are written in C++.
That seems to be exactly what you are looking for.
It's an ascii roguelike with a neat 3d aesthetic.
Godot was a pleasure to install and play around with it. I recommend taking a look!
I can't understate how much of a big deal the growing support for c# is. Both for non-game devs who want to dip their feet in making games and also luring in current Unity developers.
For example to preload a child node you put this in a node's member space.
onready var enemy = $Enemy
Variables needing to be declared with the var keyword is the biggest change in the language.
var flag = some_function_result()
Other changes include expanding Python with more keywords useful for the editor and game programming.
It is very nice for prototyping. Still looking forward to that C# AOT support in later releases.
What I have yet to try to tackle is the C import tool. Let's say I have a grid of many objects that interact with each other. I don't necessarily want GDScript to be running the logic for 10,000 objects (an extreme number, I'd likely limit it to less, but I still like the idea of keeping performance in mind). So C is a good choice. But suddenly I have to establish and maintain a big connection between GDScript and C. Everytime a feature is added it has to be added in several places. Maybe this is just the way things are done and I should just do the work. I'm worried it is the wrong way to do it.
GDScript is very comfortable for doing simple game and UI logic, but it can be problematic that there's standard/easy way to import other people's code libraries besides copy-paste jobs.
When trying to do some sort of complex logic or when I really could use an external library for something, I simply go to C# to scratch that itch, and it's been working out pretty well for me. You can even have the two languages inter-operate to a degree within a project.
If you need something only another language has to offer, unless it's a big library, conversion to GDScript is usually the matter of a few hours at most.
Otherwise for 2D another game engine I'd recommend is Love2D.
I gave up on Game Maker years ago because I realized I was pouring hours and hours into learning a language I would never be able to use anywhere else, and as much as I like Godot (and I'm really starting to like it) I feel like I'm kind of making the same mistake. Even though Godot has support for C# and third party support for other languages[0..5] I have no idea how mature such projects are, or what the long term support prospects are.
Like as not, Godot is built for GDScript, most if not nearly all tutorials assume GDScript, and any plugins you find will probably be using GDScript. You can probably assume that GDScript support is guaranteed for the future, and at best, C# support is probably guaranteed for the forseeable future, though not necessarily at parity with GDScript, version to version.
Oh, and it also apparently Godot has its own shader language so forget about using GLSL as well, probably.
As far as the language itself goes, GDScript has significant whitespace, and I don't like significant whitespace. Its idioms tend to be just unfamiliar enough to me that I keep forgetting things that would be obvious in another language. I really wish it had lambdas.
BUT... it's still a capable language and obviously it does what it says on the tin. I guess you can stick with C# or wait until one of the other language projects matures, or just bite the bullet and use GDScript. The framework itself is so much easier to deal with than Unity IMHO, and for 2D I think it's worth the frustration. All of my issues with the language, thus far, are relatively minor and entirely subjective.
Hint for people posting release announcements: you could save a great many people quite a lot of time, cumulatively, with just a single short sentence in the first paragraph of your announcement. You probably would pick up some new participants who would have given up in disgust before they could discover what the hell the thing is.
Release notes for a new version are not the place to list all the features of the engine. You can literally click on the home page and see "Object-oriented API with language options such as GDScript, C#, C++ and visual scripting.".
If people give up "in disgust" because they can't find what language the engine uses for scripting immediately in the first sentence of a release announcement then they're probably not cut out for making any kind of software which requires digging through documentation.
Nobody asked for, or needs, a list of "all the features" in a release announcement. Saying what the project is (such as that it is some kind of "engine", and maybe even what kind?) would have been a completely different, and much shorter and overwhelmingly more useful statement.
What should motivate a reader who cannot even tell what it is to spend time groveling around to find out whether they might be interested in the thing? Hint: most projects are not interesting to most people. Forced to guess, the best guess has to be "no".
I am repeatedly astonished that such elementary reasoning seems beyond so many.
As it happens, for example, a game engine in C# is of zero interest to me, but one in C++ could be quite interesting. I dismissed it as a direct consequence of the failure of the announcement to give me any reason to pay it any more attention.
Game engines this size often add many new features with every release, and the target audience (programmers and artists) want to know about all of them.
"I am repeatedly astonished that such elementary reasoning seems beyond so many."
Perhaps you're just wrong? If everywhere you go smells like shit you should check your shoes.
I feel no slight temptation to look at .NET announcements, nor to draw conclusions on good practices from them.
But all of the apoplectic rage is clearly on your side.
Is this supposed to be a joke? The information exists but you didn't try to find it.
It is the entire topic of my original post.
Really, what would be so terrible about a short sentence in an announcement so that people who don't already know all about it get some hint at what it is? No one has suggested anything like an answer. Instead, I find rage that I don't, what, just automatically go digging deep into project pages for every single new thing announced, just in case whatever it is might turn out to be interesting?
Everyone has a lot of demands on their time and attention. A person writing an announcement is necessarily trying to communicate and engage. Concealing the topic sabotages the effort, right out of the gate.
It's just one click on the logo to go their home page that says it's a game engine with some big features like being open source.
Being mysterious must provide some other benefit, to someone, if it has such vehement defenders. I know better than to ask what or who.
I don't know what axe you have to grind but what you're doing is basically the equivalent of looking at the fifth page of a bus schedule and then getting angry at not knowing what a bus is even though it is clearly written on page one.
If you want an introduction to a product then go on the home page , the features site , the Wikipedia site , anywhere except the darn release notes. People are getting angry because there are huge big fat eye catching buttons in the header that point to these pages and you're purposefully ignoring them to the point that you're basically trolling.
Really, what is so difficult about this?