I wonder if next week's Ludum Dare would be a great time to test this engine out (with a few hours prep of course). The promise of C# has been keeping me away from trying it out, but it must be at least a year now since I've heard that C# support is coming.
This is potentially a big win for me. I'm interested in Godot, but also wary of it because I didn't like the notion of a game-engine-specific language. I do like the idea of a MIT-licensed engine which works with <language of choice>, though.
I use Unity, and it's enjoyable to be able to use a widely-understood language, because of things like tooling, documentation, existing libraries. Obviously, Unity isn't perfect, particularly since being limited to .NET 2.0 often means being limited to libraries made for Unity or old versions of mainstream libraries.
Aside: Extending a game engine by linking in a shared library very much reminds me of making Quake 2 DLL mods.
My vote for Godot is that it works on Linux. What has blocked me from gamedev is the historical Windows requirement. I don't want to fiddle with virtual machines, bugs due to unsupported usage of the engine or dual boot. Electronics are very expensive in my country, so having 2 computers is a too big investment (this is also what blocks me from IOS dev btw). I need Linux because I am productive on it, and because I have an actual job besides my indie gamedev thing that requires it and I want to minimize context switch.
I have been able to run some big engines on Linux in the past, but it is always somewhat hacky and unsupported. The only game I was able to finish and launch was written in Java using the great libGDX (and I had to rent a mac in the cloud to compile for IOS (when Robovm was officially supported, don't know about how it's done now)). I am now considering Godot for my next game because it is free and runs on Linux.
Unity is fake 2D (locked orthographic 3D), and while it works for plenty of people there are plenty of reports of the tools being very difficult to use.
Godot has always been first and foremost a 2D focused engine, with 3D available if you want it. It's also far smaller and completely free (MIT) so you can make any changes you want at any level.
I don't use Unity, because throwing around vertex buffers isn't particularly difficult, but this is a pretty silly comment. Quads in an orthographic projection is what's done by literally every modern engine that's designed for any level of performance. "Fake" 2D is normal 2D in 2017.
2D is a special case of 3D. If you only want to do 2D then a 2D API is going to be simpler than a 3D API. There's a whole mess of parameters and transformations that just go away.
Do you really think Unity has great 2D tools? I tried it multiple times over the last couple years and always found it felt bloated and exactly like a 2D toolset bolted onto a framework really meant for 3D, instead of like a proper 2D-native engine and IDE.
I'm in the same boat. I tried for multiple years and I've been waiting for their experimental preview of their 2d tools since last summer. As someone who's rolled their own and has tried Unity, Godot, and GameMaker, I'd rather roll my own or use GameMaker than use Unity or Godot. I've found GameMaker Studio 2 to be quite nice.
If Unity ever finishes their experimental support for Tilemaps and other features, I'll try it again.
Also a fellow passenger on the USS mdorazio / wmccullough. I have ended up using Unity lately because of 1) collaborators and 2) it works on my preferred development environment (Mac). That said, I'm pretty interested in the upcoming GM:S 2 mac release; I wasn't fortunate enough to be part of the beta.
Speaking as someone with experience with Unity3D and not Godot:
Unity3D's design is not very good. It is a popular system, you can find a lot of hacks online for getting common things done, but overall the thing is a garbage heap of unorganized and poorly documented features.
The ability to work with source control is a joke. I'm sorry, you can't do professional grade software development without source control. You really shouldn't be doing hobby grade development without it either. But Unity makes you jump through several hoops to get source control working correctly and reliably.
They have an asset store that almost looks like a package manager, but isn't, leaving you to have to check all of your plugins into your repository rather than redeploy out of the central store.
Patch-point releases frequently introduce breaking changes. And their project format is locked to prevent you from opening a project that had just been opened in a newer version than the one you have. Yes, opening a project in Unity writes changes to disk. Wouldn't be so bad of a problem if your project could easily and trivially be added to source control and you could just reset the changes, but see above.
It makes doing basic physics very easy to do, but the quality of the physics is not very good. Even their heavy number crunching "continuous dynamic" mode suffers from terrible warp-through problems.
It's still, after all this time, not available for working on Linux. You can build games that run on Linux, but you can't do the work on Linux.
The export to WebGL feature is another joke. An empty project ends up dumping around 50MB of code out. That's before you even get to any game code or assets. They compile your C# code to CIL with Mono, then that gets converted to C++ with IL2CPP, then that gets converted to ASM.js with Emscripten. It's an absurd Rube Goldberg machine of a process that it's no wonder people thing WebGL sucks, if all they have to go by is Unity projects.
It bombs you out to Visual Studio for editing code, but it's still not compatible with any version of .NET post 2.0. You can't import DLLs without hacking the *.csproj file by hand.
I'm sure I could come up with some more gripes if I thought about it for a while, but I don't want to be here all day.
Although it is buggy, I use the Linux editor regularly. :)
> And their project format is locked to prevent you from opening a project that had just been opened in a newer version than the one you have
Related pet peeve: The Linux editor appends "Linux" to the project version, forcing a complete reimport of all the assets when moving between the Linux and Windows editors even if they're actually at the same version.
A lot of valid points, but what problems did you encounter with source control? I have worked with big commercial projects with Unity3d, and maintaining all assets serialized in text didn't bring much pain with a minimal discipline.
Text assets should be the default and only option, just opening the project shouldn't change any files, and saving on a different computer shouldn't arbitrarily change the metadata files. Hell, they need to give a really good explainanation for what is even the point of the metadata files, because no other IDE worth its salt has such a noisey system.
And that does suck, speaking as a developer, I MUCH prefer working in linux. The exception would be .net/C#, you just can't beat visual studio in that environment.
Even then though... I still use the git bash console/tools for everything. love me some grep.
I don't have any experience with Godot. But given a choice between GameMaker: Studio and Unity3D for 2D, I choose the former. And it's because of the tooling. I don't consider Unity3D's tooling to be great for 2D. I don't consider it poor, either. But I think in making a good engine that offers 2D and 3D, some of the workflow is suboptimal if you're only working with 2D. That said, I've used Unity3D lately even for 2D projects, because my collaborators have been more familiar with it.
Unity requires you to sign up for an account in order to use it. As a consequence, your unity account could be terminated, severing your ability to work on your own projects as a result.
I know the Unity guys feel they're being reasonable and that it's a mainstream thing to require an account for a product, but I will never -ever- voluntarily lock my own personal projects inside someone elses system like that, and I think it's pretty galling of them to think they deserve that much control over my work.
Godot is super easy in 2d if you understand scene-tree-node philosophy and you have nothing agains thier variation of python. API is small, IDE is good, works great on linux.
Personally I'm using it for prototyping, my main engine is UE4 though.
I'm thinking that maybe it's time to create a small but full game with it.
Off Topic: Is it just me or are the trolls out in force today? People in this thread shitting all over game development. Seriously, if you're just off work for the holiday weekend, go outside. Stop screwing up perfectly good HN discussions because your ego feels threatened.
Why stop there? Imagine what we could achieve if we didn't "waste" resources on anything that was purely for entertainment, e.g. most movies, lots of facebooking/instagramming/twittering, restaurants focusing on making food that is more than bare sustenance, etc.
Instagram isnt hard to build compared to game engine. Making food is not the same as highly skilled engineer. Drinking in a bar doesnt make you a scientist.
They're both hard to build, but require different skillsets. Moreover, game engines are often customized in unhygienic ways by folks early in their career. Maybe it's better these inexperienced folks run into the problems with their own unmaintainable code firsthand before they take on world-critical problems.
I am a game-engine-developer... without any work at the moment.
People just rarely want my skills, I work with C, C++, Lua, ASM, blazing-speed well built code that takes a long time to make.
People don't even ask me to do interviews, when I see all these posts on HN complaining of interviews I can't relate, I never get invited to them in first place, because I don't know React, Enterprise-Java, Electron and other whatever new very high-level tech designed to speed up dev (at cost of program speed for end user) that is popular.
Game engines have a lot of similarities with the problems in Robotics. Given an array of on-board sensors you need to build a model of your environment, plan through it, behave intelligently, and network information with other robots or human users. Furthermore to validate the product you need a simulation environment and engines like Unreal are starting to be used to do so (https://github.com/Microsoft/AirSim). High performance code is key to making it all happen in real time and C++ is the native tongue.
I work at http://shield.ai/ and we're building these robots today. Our mission is to reduce American and civilian casualties to 0 by 2030 in ground combat. If you're interested - here's my email adam.dorwart [at] shield [dot] ai
A lot of ex-gamedev(I'm one of them) go into embedded devices and mobile where power/perf still matters or over into financial(more common in eu gamedev) where latency is king.
That's the route I took(gamedev->embedded/mobile->bigco), I'd look into those type of companies where a low level native skillset matters.
There are plenty of jobs available for game engine developers, and low level engine programmers in general. If you'#re applying for jobs with React/Electron in the descriptions, you're not really applying for engine developer positions, though.
Where? Mind you, I don't live in a first world country... So it must be either remote, or allow relocation. (in my country at least ALL jobs are for React/Electron/Java... I applied to them because they are the only job listing that existed in first place, better to work on the 'wrong field' than to be hungry).
I don't know where youre located, but in many parts of the world there are low level c++ jobs available. The us and Europe are full of them, and every company I've spoken to has offered relocation.
There's a difference between people not wanting your skills, and people not wanting your skills where you're located, unfortunately.
I doubt that. If you're referring to the people adding the json datatype & operators, there's little overlap with the people working on replication related issues.
Did it occur to you that many of these people might not want to do something else and would then actually not accomplish what they'll accomplish in an environment they actually enjoy?
Come on man, I know. But, many of these guys started as game-players at a young age (I learned programming to make games, and saw that it was more fun compared to creating, actually transitioned to easier webdev programming). If we could incentivise them somehow at a young age, maybe even just provide more options.
Good on you. Maybe when you acquire more smarts you'll realize that games are an essential part of how we got to where we are as a species and that "using" all the game devs on "more productive" stuff could regress us.
Maybe somewhere in that transition you'll also take note on how many technological advancements originate from the game development field.
I'm thankful we don't have managers at the top of the chain, deciding what the human species should and shouldn't spend their professional time on, based on an extremely narrow and stereotypically uninformed world view.
Depending on who you ask, the same opinion could be held for developing programs relating to banks, market trading, movies, government...the list goes on.
What if people want to develop game engines? What if people want to play games? What if personal passions are an important part of life? What if it isn't your time to allocate, but theirs? What if throwing a bunch of game developers onto protein folding wouldn't really help with protein folding anyway?
Plenty of people bought graphic cards to play games and use them for protein folding in their spare time, thanks to Folding@Home. Sometimes leisure activities produce practical results.
Why not a step further? Why allow entertainment of any sort? Surely musicians and artists could best be served pumping gas and digging ditches, as well! \s
