[HN Gopher] It's time to make that indie C# game in Godot
___________________________________________________________________
It's time to make that indie C# game in Godot
Author : proxybop
Score : 306 points
Date : 2022-07-14 14:35 UTC (8 hours ago)
(HTM) web link (jolexxa.medium.com)
(TXT) w3m dump (jolexxa.medium.com)
| luxuryballs wrote:
| I'm in the midst of making a 2d game in monogame and was toying
| with switching to Unity, thanks for sharing this. Man I wish I
| could find some resources on how to do 2d shaders in monogame
| though, like making sprites wave in the wind/water without
| needing a ton of sprite frames, hard to find this kind of thing.
| rfrerebe wrote:
| There is a book that actually tells you not wait for Godot :
| https://en.wikipedia.org/wiki/Waiting_for_Godot
| debacle wrote:
| Unity is suffering because it can't find a way to make DOTS/ECS
| first class without completely redoing basically everything.
|
| That's my biggest complaint with Unity at this point. So much is
| built around the GameObject implementation that when you start
| using ECS you can feel the friction - you're writing a lot more
| code, you're doing things in a way that feel like swimming
| upstream, and there's less support + documentation.
|
| How does Godot compare? Are highly threaded features out of the
| box? I would use Unreal but the C# Unreal interfaces I've seen
| are very immature.
| Mikeb85 wrote:
| > How does Godot compare? Are highly threaded features out of
| the box?
|
| Ish. But Godot very much embraces OO. Everything is a node
| extending another node with messages passed between. But IMO
| it's OO done right.
| debacle wrote:
| OO doesn't matter if you want to simulate 100k objects at
| once without slowdowns.
| berkut wrote:
| ECS on its own doesn't always help - it's not a magic
| bullet for every situation: sometimes you need to use
| spatially-aware data structures / acceleration structures
| for those type of "queries", and vanilla ECS (i.e. similar
| to a DB in terms of queries) doesn't always help you in
| these type of situations.
| Mikeb85 wrote:
| And how many games actually do that?
|
| Also, if you really want, with Godot you can bypass the
| scene node system and also just use C++.
| overgard wrote:
| This might be of use: https://godotengine.org/article/why-isnt-
| godot-ecs-based-gam...
| idle_zealot wrote:
| Godot also seems to be built in a way that creates friction for
| ECS style game logic. It's built around scenes that are trees
| of nodes that each have associated behavior and
| signaling/message passing between nodes.
| UnpossibleJim wrote:
| There is an ECS port for Godot named Godex, but it isn't
| hugely mature:
|
| https://github.com/GodotECS/godex
|
| I haven't used it, though I've been curious about it. As far
| as better options for ECS game engines go, I'd go with Bevy
| (personally), but you'll have to learn Rust (which I'm a
| proponent of anyway).
|
| https://bevyengine.org/learn/book/introduction/
|
| But both of these are still in "Beta", if that's even the
| proper term for their development cycle, at this point. They
| work, technically, but they could use some help, to my
| understanding.
| TillE wrote:
| If you're doing high-end 3D stuff, Godot 3.x will probably
| disappoint you anyway.
|
| If you're doing graphically simple games with a complex
| simulation under the hood (everyone loves RimWorld as an
| example), then you don't really benefit from an ECS that's
| tightly integrated with the engine. You just do all that stuff
| however you want, and use the engine as an I/O layer.
| debacle wrote:
| If I want a system that supports plugins, etc, and there's no
| uniform way of doing that, then I'm doing things from
| scratch, though.
| brundolf wrote:
| > If you're doing high-end 3D stuff, Godot 3.x will probably
| disappoint you anyway
|
| Maybe 3.x, but I've seen/read some exciting stuff about 4.0's
| graphics engine
| throwawaycuriou wrote:
| Would be popcorn to see Epic make a saucy donation to the Godot
| project at this time.
| arminiusreturns wrote:
| I'm so happy that I saw this coming and have been head first in
| master branch in order to be ahead of the curve. I have lots of
| things to learn still in 4 but I see clean piplines using latest
| formats like dynamic gltf in scene reload, meaning direct
| blender(et al)-godot pipelines. Global illum is so off the charts
| pretty. Perf is a pain point but when you start using
| multimeshinstances things make more sense. Updates sometimes
| corrupt scenes, keep your source of truth models in gltf 2.
| Shader language wizards are the future. Vulkan is the coolest
| thing since sliced bread.
|
| Context: My game project has been going since 2013, on godot
| since 2018.
| KronisLV wrote:
| > Godot doesn't fight you when you're building scenes. Making a
| scene feels a lot like creating a class using composition, and
| scenes can even inherit from other scenes (using another scene as
| the the root node of a scene allows you to inherit from it and
| override its properties in the editor and in code), allowing you
| to express patterns you're intimately familiar with from object-
| oriented programming.
|
| I personally find the approach of nodes everywhere a bit odd.
|
| In my mind, you'd typically use nodes for objects that are
| supposed to represent some sort of an object or concept within
| the scene, whereas the scripts would be the ones that actually
| give said object any number of behaviors, such as a certain group
| of functionality per script.
|
| So you might have something like the following:
| EnemyObject PathfindingBehavior ShootingBehavior
| TalkingBehavior
|
| Unity kind of vaguely got that "right" (e.g. in a way that's
| subjectively intuitive to me) with its component system.
|
| Whereas in Godot you can only have one script per node, which
| would mean that in practice I'd have something like:
| EnemyObject PathfindingObject
| PathfindingBehavior (attached script) ShootingObject
| ShootingBehavior (attached script) TalkingObject
| TalkingBehavior (attached script)
|
| It kind of feels like it would be nicer to be able to attach a
| number of scripts to the object that I actually want to control,
| instead of having Nodes that I don't really see much of a use
| for, apart from them being script containers.
|
| Of course, maybe that's just because I'm used to the GameObject
| pattern that Unity uses, an entity-component system (of sorts),
| though that implementation has gotten a bunch of critique as
| well, with DOTS apparently being a better ECS approach, though
| also unfinished in certain aspects.
|
| Just felt like sharing my thoughts on that particular aspect,
| which some might find curious and which might take a bit of
| getting used to (though personally not having a separate "prefab"
| concept and instead having more or less everything be a node is
| also pretty freeing, I have to say).
|
| With a bit of love, using C# could also be pretty amazing, since
| GDScript does have certain limitations (performance comes to
| mind, for when you need it to be decent for number crunching but
| don't want to/can't use C++ due to knowledge or other
| restrictions, C# has your back there) and curious design choices
| (the integration with the engine is super nice and the Python
| like syntax is great, but having to define singletons in the
| editor IIRC is a bit silly
| https://docs.godotengine.org/en/stable/tutorials/scripting/s...).
| hitpointdrew wrote:
| Why not just use the native GD Script? IMO is far easier and
| cleaner to read than C#.
| joemi wrote:
| I think the article mentions it because Unity primarily is with
| C#.
| mindwok wrote:
| Two reasons I can think of:
|
| 1. C# in Godot is faster than GDScript.
|
| 2. The type safety features of C# are a bit more mature (and
| non-optional) for C#
| jayd16 wrote:
| Hopefully the async/await story gets fleshed out. Unity just made
| the default scheduler run on the main thread. That's pretty much
| all it takes but it would be nice if it was built in.
| 202206241203 wrote:
| Also check MonoGame - used by Stardew Valley etc.:
| https://www.monogame.net
|
| It's a framework not an engine though - more programming from
| scratch rather than scripting pre-existing things in a visual
| editor.
| everyone wrote:
| How easy is building to mobile in Godot?
|
| I have been a Unity dev for years and my main reason for using it
| is that I can build to most platforms with relative ease from the
| one engine.
| pipeline_peak wrote:
| > It's no secret that Unity is painful to use: it's slow to open,
| and it often pauses to re-scan the entire project while you're
| trying to work
|
| Is this actually true? I always figured Unity's selling point was
| being lighter and easier to use than unreal.
|
| Godot looks like Unity from 2008, it's easy to boast efficiency
| when you have a limited product.
| disintegore wrote:
| This seems to be a cyclical thing. Every now and then a new
| solution shows up that is built on new development and UX
| practices, abandons some baggage that is no longer relevant to
| most users, makes assumptions in its design that are better
| suited to the era, etc etc.
|
| Then ten or twenty years pass and it becomes the thing to
| replace.
| psyc wrote:
| I switched to Unreal after using Unity for many years, both at
| my day jobs and as an indie. If I had known what it is actually
| like to work in Unreal, rather than how the grapevine vaguely
| typecasts it, I would have switched a long time ago, or more
| likely never used Unity in the first place. Unreal is a
| delight.
|
| It's unfortunate that Epic ever let Unity persuade people that
| it's better suited to anything or anyone at all.
| overgard wrote:
| It's very true; I remember one game I was working on, when you
| pulled down the code and new assets it'd take a long time to
| rebuild the "Library" (which is not something you can check
| in). And sometimes, if your version of the project was acting
| wonky and everyone else was fine, the solution was to delete
| the Library and rebuild it from scratch. If you were doing it
| from scratch, it could take hours. They've made some
| improvements but it's still a mess.
|
| The editor itself always seems very buggy. If you have the
| "Console" open (which you will if you're coding), it's pretty
| much guaranteed you're going to see a lot of random errors that
| have nothing to do with even your code. A lot of them don't
| even make sense or could be ignored. Like you'll get weird
| asset import errors if you upgrade versions, but a lot of times
| they're just red herrings and not important. There's also a lot
| of QOL stuff that's very frustrating, like arrays being
| annoying to edit (I'm not sure if they've fixed this yet or
| not). It's also easy to accidentally brick your editor on your
| own, with debugger shenanigans or loops that don't end.
|
| Also, if you're trying to build a an editor extension, omg was
| that a nightmare. Just getting things like Undo/Redo and object
| serialization working correctly are difficult and in some cases
| impossible. And frankly, you need extensions for a lot of
| things to actually be useful, like until recently the builtin
| terrain editor was basically useless, and you have things like
| Odin because the builtin inspector is a nightmare.
|
| There's a lot to like about Unity, but there's also a huge
| amount of pain points with it.
| okwubodu wrote:
| Personally, I think they were a bit generous there.
|
| I'm not sure what it is but it's gotten significantly worse
| over the past few years and I've stopped recommending it to new
| game devs.
| Uehreka wrote:
| It is outrageously painful. Half of the craft of working in
| Unity is knowing which kinds of operations will trigger a 15
| minute re-import and basically scheduling your day so that you
| have other things you can do while that's happening. It doesn't
| happen every day or every time you open a project, but
| sometimes you'll be looking at your master branch in git, and
| then you go to check out a branch where something big has
| changed, and then you alt-tab back to Unity and... time to go
| make a fresh pot of coffee.
| KronisLV wrote:
| > Is this actually true?
|
| I'd say that yes, at least in the last 5 or so years.
|
| I decided to make a scene which would contain a single copy of
| every single model that I'd like to use in a project of mine,
| for checking the textures, how lighting works, the scale of
| everything etc.
|
| By the time I got to around 200 different objects (no high poly
| ones, by the way), it took like a minute to just open that
| scene.
| sfteus wrote:
| Anecdotally, there's something about Godot's structure that
| just "clicks" better for me. It's odd because they seem pretty
| similar on the surface (nested scene graph, nodes with scripts
| that have hooks, etc), so it's hard to determine what exactly
| makes it easier to understand.
|
| The only two concrete things I can point to are better
| documentation (IMO), and the first-class signal/observer
| support in Godot. I'm not sure if that exists in Unity or not,
| but it's a really intuitive way to handle entity interaction,
| and I think that makes it way more easy for beginners to get
| started.
| Entinel wrote:
| Anyone who used Unity 2.x in 08 would tell you Godot is far
| beyond where Unity was in 2008 in terms of features and
| stability.
| scottymac wrote:
| Especially for 2D features.
| BoorishBears wrote:
| As someone who did I'd say it's a silly comparison. Godot has
| a decade of advancements in technology on Unity 2.x, things
| are generally "nicer" than when Unity started
| johnfn wrote:
| The quoted statement is 100% accurate. Unity is very slow. When
| I worked on Unity with a larger project, I'd often have to wait
| 10+ seconds for Unity to rescan the entire project every time I
| switched windows from my IDE to Unity, or every time I ran the
| project. In similar project sizes, Godot was always lightning
| fast.
|
| > Godot looks like Unity from 2008, it's easy to boast
| efficiency when you have a limited product.
|
| Unity does have more features - like more obscure 3D features -
| but that has nothing to do with how Unity deems it necessary to
| rescan the project tree all the time. Also, when I used Unity,
| I never used these extra features, so even if this were true,
| how come _all_ users have to pay the price for features that
| only a few of us will use?
|
| Honestly, core Godot is very full-featured, and in my
| experience the central abstractions are much better thought out
| than those in Unity. I feel a lot of the FUD around "Unity has
| more features than Godot" comes from people that like seeing a
| long list of features, not from people who actually need those
| features.
| eatsyourtacos wrote:
| Agreed- my limited Unity usage has been horrible just because
| of how bloated and massive it seems every time I try to give
| it a go.
|
| Whereas Godot opens up in literally 1 second and boom I am
| there.
|
| And for 2D projects, there is very little "lacking" compared
| to Unity. It's way more clear what is going on.
| TillE wrote:
| > the central abstractions are much better thought out
|
| Totally agree. Godot is the first engine I've ever used where
| I don't feel like I'm fighting with it the whole time to make
| it do what I want.
|
| Godot is pretty clearly a solid choice for anyone making 2D
| games, and will eventually be a fantastic choice once we get
| a stable Godot 4.0 with .NET 6 and other nice features.
| aroman wrote:
| As someone who uses Unity professionally to make a 2D game,
| here are some key areas I find godot lacking vs unity:
|
| - Scalable text support a la TextMeshPro (sdf-based
| rendering)
|
| - the in-editor console is horrible. it frequently tells me
| "output overflow, print less text!". wtf? also, it doesn't
| let me click on a line to jump to the code
|
| - the built-in tile editor is very painful in my experience.
| the UI is clunky and it's lacking important features I depend
| on in Unity, like tile rules.
|
| - the built-in text editor is _very_ basic, and support for
| external editors is limited vs Unity (and hampered by lack of
| mature tooling for gdscript vs C#)
|
| - gdscript's heavy reliance on "magic" strings and lack of
| type-safety throughout
|
| - unity's UI system sucks, but it's still more capable than
| Godot's especially for things
| jolexxa wrote:
| I believe I can address the first two points for you:
|
| > Scalable text support a la TextMeshPro (sdf-based
| rendering)
|
| Someone in our Discord recently found a way to scale their
| project UI correctly according to screen DPI, not sure if
| that solves your problem or not. Their project is also open
| source: https://github.com/derkork/openscad-graph-editor
|
| > - the in-editor console is horrible. it frequently tells
| me "output overflow, print less text!". wtf?
|
| That can be solved by upping the debugger output limit in
| your project. (https://github.com/chickensoft-
| games/go_dot_test/blob/1fb342...)
| aroman wrote:
| Thanks for the reply! Can you share any more context on
| the scalable UI solution? Feel free to tag me in the
| thread on Discord, my handle is avi#9876.
|
| Also TY for the tip about debugger output limit -- no
| idea why the default is so low!
| johnfn wrote:
| > Scalable text support a la TextMeshPro (sdf-based
| rendering)
|
| Agreed, this could be better.
|
| > the in-editor console is horrible. it frequently tells me
| "output overflow, print less text!". wtf? also, it doesn't
| let me click on a line to jump to the code
|
| Agreed.
|
| > the built-in tile editor is very painful in my
| experience.
|
| Agreed, but I hear it's better in 4.0
|
| > the built-in text editor is _very_ basic
|
| Actually, I disagree here. Fuzzy find, quick open, search
| in files, and autocomplete all work and are blazing fast.
| It is missing some things like a decent Vim mode, I'll
| admit. However, I tried both using vscode and the godot
| text editor, and I found that you saved so much time by not
| having to jump between IDE and Godot that it actually made
| up for a few of the more minor deficiencies.
|
| > gdscript's heavy reliance on "magic" strings and lack of
| type-safety throughout
|
| Agreed, but this improves in 4.0.
|
| > unity's UI system sucks, but it's still more capable than
| Godot's especially for things
|
| I honestly find Godot's workable enough. With Unity I would
| get into stupid issues because it was scaled 1000x larger
| than my game (who in their right mind thought this was a
| good idea?!?). Also, I remember Unity having 3 different
| modes for their UI, all of which were confusing and counter
| intuitive. Godot's UI is simple enough to hack.
| aroman wrote:
| Thanks for the detailed reply. I am super excited about
| 4.0, I eagerly read the alpha update blog posts when they
| appear in my RSS reader :D
|
| I am probably most excited about the gdscript 2.0
| features. As someone who currently maintains a fairly
| large codebase as a solo developer, I cannot imagine
| writing that in gdscript. I rely heavily on C#'s type
| safety and more "industrial strength" tooling -- a strong
| standard library, huge ecosystem of tested open source C#
| modules (e.g. NuGet), great external IDE support (I use
| Rider), and a lot of language features like generics and
| interfaces.
|
| Btw on the UI stuff... I definitely remember being very
| confused about that when I first got started. Now, I
| actually do see the benefits of having 3 separate modes
| -- it "does the hard work for you" when you want to put
| UI in screen space vs world space. But yeah Unity's UI
| system isn't good... and, like seemingly everything else
| in Unity's, it's apparently deprecated yet it's
| proclaimed replacement (UI Toolkit) isn't production-
| ready. Sigh...
| corrral wrote:
| > - gdscript's heavy reliance on "magic" strings and lack
| of type-safety throughout
|
| Yikes. I was like "eh, I could get over that for a good dev
| framework" until I hit this one. Dealing with that kind of
| thing is like driving a car with hexagonal wheels.
| johnfn wrote:
| It's actually not as bad as it sounds. There are
| generally 2 cases where these come up.
|
| 1. As a hack for not having functions as first class
| objects in GDScript - you'd refer to the function by
| string name. This definitely felt very hacky, but it's
| been resolved in 4.0, and now we have first-class
| functions!
|
| 2. For some things that other languages would handle as
| enums. This is also a problem, but it's not nearly as bad
| as you'd think, because it's generally fairly readable -
| stuff roughly like `is_key_down("key_left")` - and
| because Godot's autocomplete is good enough to suggest
| only the appropriate strings.
| bluefirebrand wrote:
| I love working with Godot but I can't help but feel like
| GDScript is a mistake.
|
| I want better language support and community when working on
| a project. I want to use nice VSCode plugins that auto format
| my code (and give type hints... Untyped languages hurt me so
| much these days)
|
| I can't wait for better C# integration for Godot. It's ok now
| but I'd love it to be rock solid.
| kevingadd wrote:
| Custom scripting language seems to be a common error -
| early on Unity emphasized a pseudo-custom scripting
| language (Boo) over C# and had to slowly extract it out of
| the product, documentation etc.
|
| It makes sense as a risk management strategy early on in
| engine development, though, since integrating something
| like C# can be difficult and they may have been afraid that
| they would regret building around C# later on.
| bluefirebrand wrote:
| I do wonder if integrating C# is more effort than
| building and maintaining a language though.
|
| But I do understand it. I just am not sure it's a good
| strategy for longterm growth.
| bluescrn wrote:
| Pushing people towards a non-standard scripting language
| is definitely not a strategy for long-term growth.
|
| It needs a widely-known language with good performance
| and high quality debugging support (you can use the
| Visual Studio debugger with Unity C# or UE C++, for
| example)
| danbolt wrote:
| Normally I'd agree with you, especially as someone that's
| embedded a scripting language into AAA games, but I think
| GDScript is the exception to the rule. Or, it's very
| tightly integrated with the engine's way of handling
| memory and it feels refreshing compared to a VM that has
| some bindings to native functions.
| krapp wrote:
| On the one hand, Undertale, Spelunky, Hotline Miami and
| other popular games have been made in GameMaker and GML
| is much, much worse than GDScript. At the end of the day,
| the player isn't going to care.
|
| On the other hand, GDScript is not that great a language.
| No one would use it as a general purpose scripting
| language outside of Godot, it's like a more awkward
| wannabe Python without many of Python's useful features,
| and outright frustrating features like "pass" and funcref
| and not actually being able to type-hint signals.
|
| To each their own, but I've never enjoyed using GDScript,
| which is unfortunate because the framework itself is
| amazing.
| thrillgore wrote:
| The only real FUD that has any basis is 1) The lack of good
| 3D support and 2) DOTS style architecture. These are things
| the community is addressing now for future releases.
|
| The 3D support will be significantly overhauled in 4.x
| https://www.youtube.com/watch?v=DNJXkcQxXEg and additional
| enhancements will reduce the need for DOTS/ECS for many.
| There's also Godex https://github.com/GodotECS/godex that
| adds ECS to the engine.
| jayd16 wrote:
| Are you comparing apples to apples with similar sized
| projects? I'd be curious to hear about larger Godot projects.
| johnfn wrote:
| Yep. Similar numbers of assets, similar sizes of assets,
| etc. Things that would cause Unity to keel over and die
| were virtually instantaneous in Godot. I had a project with
| something like 10k game objects in Godot with no major
| issues.
|
| Actually, there _was_ one issue where saving was taking
| like 5 seconds in Godot instead of being instantaneous. I
| reported it and it was solved in the next point version.
| https://github.com/godotengine/godot/pull/49570
| jpeter wrote:
| I recently tried out unity with this tutorial
| https://www.youtube.com/watch?v=_Pm16a18zy8 and imported a
| sprite map. It took like 10 minutes to load. No idea why it
| takes so long
| Dracophoenix wrote:
| Would you still recommend Unity for 3D iOS game development,
| or would it be better to move on to Godot?
| johnfn wrote:
| Hmm, it depends how much you're going to be using the 3D
| features that Unity provides. If you're going down the big
| list of Unity 3D features and you're thinking you need a
| whole bunch of them, then it's possible that Unity would be
| a time save in the long run. But honestly I like Godot so
| much that it would take a lot to tip the scales.
|
| I would personally not use Unity at all because I find the
| developer experience so frustrating. I'd rather spend an
| extra couple of days enjoyably hacking something together
| rather than spending less time in more frustrating ways
| (like waiting for compiles). But I feel I'm more sensitive
| to these things than most people.
| Zhyl wrote:
| With 4.0 getting more and more advanced features [0] and Unity
| merging with an Ad company [1], Godot is looking like it could be
| an attractive proposition for a lot of Unity shops.
|
| [0] https://news.ycombinator.com/item?id=32003065
|
| [1] https://news.ycombinator.com/item?id=32081051
| bluefirebrand wrote:
| It's definitely Godot's opportunity to drive a lot of adoption,
| I'm seeing a ton of disgust from a lot of indie devs I follow,
| and looking for alternatives to Unity now.
| Thaxll wrote:
| Godot is an amateur project compared to Unity, it's not even
| close. What game actually shipped on Godot? I can't cite a
| single major game on it.
|
| https://godotengine.org/showcase
|
| Looking at any of thoses games looks bad tbh it's like weekend
| project / low indie games.
| AaronM wrote:
| Sonic Colors: Ultimate, made by Sega.
|
| Here are some other games
|
| Carol Reed Mysteries[53] (since 2021) Commander Keen in Keen
| Dreams (Nintendo Switch port only) Cruelty Squad Deponia (iOS
| and PlayStation 4 ports) The Interactive Adventures of Dog
| Mendonca & Pizzaboy Hardcoded Kingdoms of the Dump Sonic
| Colors: Ultimate
| carbadtraingood wrote:
| Sonic Colors remaster, iirc?
|
| The games in that showcase look pretty decent to me? Plenty
| of games I play look like that, lol.
| idle_zealot wrote:
| If I'm remembering correctly the new UI elements in the
| remaster were done in Godot, but the actual game was not.
| The new Godot menus are slow and unresponsive, so Colors
| isn't a great showcase for Godot.
| bogwog wrote:
| > weekend project
|
| If Godot lets you make games like that in a weekend, then
| it's lightyears ahead of Unity.
| drusepth wrote:
| FWIW, I'd bet I could replicate many of these games sans
| release polish in a weekend in Unity solely because of
| their expansive asset store. Building them from scratch
| would take longer, but not that much longer.
|
| If Godot had even the beginning of an asset store, it'd be
| way more appealing to devs like myself migrating away from
| Unity. Especially with Unreal's recent megascans and Quixel
| integrations making their asset store look _inspiring_ , I
| can't imagine many Unity studios (who, IME, primarily focus
| on rapid development and tooling over asset work) will be
| drawn to Godot.
|
| Obviously context is important, though: the asset store
| isn't the end-all reason people use Unity and rarely the
| reason a studio chooses the engine, but it is still a big
| factor for both groups. Other factors will apply, YMMV,
| etc.
| Thaxll wrote:
| Lot of AAA studios use Unity to prototype games when they
| have in-house engine.
| eropple wrote:
| Godot is really cool, but a clear and publicly delineated path
| to console distribution (and not "go talk to these guys", as
| they currently do) is going to be necessary to get material
| interest out of most of the gamedev space.
| remram wrote:
| The consoles make this explicitly incompatible with open
| source though. That could possibly be a separate entity I
| suppose, or hopefully if Godot becomes big enough the
| consoles could arrange something.
| to-too-two wrote:
| I'd love official console support but it's not possible being
| open-source. Porting it yourself is an option, but not many
| will be inclined to do that and would have to opt for paying
| a third-party to do so.
| TulliusCicero wrote:
| Couldn't you just have a bridge library of some sort that's
| not open source and contains only the console-specific
| code?
| to-too-two wrote:
| From the official Godot docs:
|
| _The reason other consoles are not officially supported
| are:_
|
| - _To develop for consoles, one must be licensed as a
| company. As an open source project, Godot does not have
| such a legal figure._
|
| - _Console SDKs are secret and covered by non-disclosure
| agreements. Even if we could get access to them, we could
| not publish the platform-specific code under an open
| source license._
|
| - _Consoles require specialized hardware to develop for,
| so regular individuals can 't create games for them
| anyway._
|
| Source: https://docs.godotengine.org/en/stable/tutorials/
| platform/co...
| wly_cdgr wrote:
| Yes. This is the main and only major thing that is holding
| Godot back from mass indie adoption. I would choose GMS2 or
| Unity over Godot for a 2D commercial indie project even
| though GML is worthless on a resume and Unity has all the
| Unity problems, because they build to all the consoles. Or
| Defold, since it is really nice and at least can target
| Switch. And I would choose Unreal or Unity or maybe even
| Cocos Creator (which recently added Switch support) for a 3D
| project for the same reason.
|
| If you want mass adoption, you need to make it financially
| viable for commercial indies to use your engine, and good
| luck convincing those people if they know they need to hire a
| 3rd party company to port to consoles.
|
| Since Godot can't really go the console route, though, they
| basically need to do the work of figuring out how their users
| can make enough money on just web, mobile, and/or desktop,
| and then articulate and successfully sell that solution to
| them. Steam Deck could help for sure, but it's a big ask
| TulliusCicero wrote:
| > Since Godot can't really go the console route
|
| Wait, why not? I thought it was a deliberate choice on the
| devs' part not to prioritize native support for consoles,
| not something that's actually impossible (since obviously
| other third party engines do it).
| skneko wrote:
| As explained in [0]:
|
| - To develop for consoles, one must be licensed as a
| company. As an open source project, Godot does not have
| such a legal figure.
|
| - Console SDKs are secret and covered by non-disclosure
| agreements. Even if we could get access to them, we could
| not publish the platform-specific code under an open
| source license.
|
| [0] https://github.com/godotengine/godot-
| docs/blob/master/tutori...
| spywaregorilla wrote:
| Unity is already an ad company
| TaupeRanger wrote:
| How's networking in the recent Godot versions? Anything
| innovative or extra helpful in that space?
| BlargMcLarg wrote:
| C# hasn't been an issue for me at all bar a few oddities. Some
| things not working properly in C# (think some plugins or
| something back a while ago). Some code not directly mapping from
| GDScript to C#, causing huge object count issues. For reference,
| I've been using it since 3.1 in a hobby context.
|
| Really, it's not the developers you have to worry about. It's
| everyone else. Godot is made with developers in mind, but there's
| much more to do than wiring signals and writing code. If you
| can't map things one to one from a different program or close to
| that through a plugin, you're either giving yourself more work,
| or forcing not just developers, but artists to relearn processes
| too.
|
| The small stuff will get fixed over time.
| sfteus wrote:
| > If you can't map things one to one from a different program
| or close to that through a plugin
|
| I've only used Godot in a hobby context, but the full on C#
| support compared to other engines is pretty amazing. Just as a
| proof of concept I imported an open source C# library I've
| worked on that's designed to play old DOS music formats,
| created a small wrapper node with control functions, and I was
| able to control it as expected from within GDScript nodes right
| out of the box. Only issue I would have seen down the road
| would be cross-platform compatibility since the library itself
| was Windows only.
|
| Caveat: I can't say I've ever got far enough in Unity to say if
| the C# support is of a similar scope. Godot just "clicks"
| better for me, so I've gotten way farther with it than anything
| I've done in Unity.
| BlargMcLarg wrote:
| Yeah, that works well. Most libraries do work depending on
| target platform. With C#, you can write your entire logic
| outside Godot and just use Godot as a graphical interface if
| you so desire.
|
| But that's the point. We're discussing things from a
| developer point of view. This happens almost every day by
| now. That's not the issue. The issue is how everyone else
| struggles with Godot compared to Unity, if at all. When even
| basic particle patterns require diving into shader logic in
| 3.4 or loads of trial and error, that's a pretty hard sell
| for non-technical people.
| aschearer wrote:
| I'd love an alternative for 2D games to Unity but I haven't found
| one that has the breadth of features as well as demonstrated high
| quality games. It doesn't help that Godot fans constantly push
| their engine-of-choice every chance they get. We get it, you're
| excited... Show, don't tell. Build super high quality stuff and
| prove it's time to stop waiting.
| prophesi wrote:
| Maybe it's because writing C# in Unity is really just using the
| Unity SDK and not writing actual C# code, but I wouldn't want to
| hop over to Godot just because it supports C#, as learning it was
| born out of necessity and was never an enjoyable experience. I'd
| be much more interested in their GodotScript or plugins for other
| languages I'm familiar in.
| Shadonototra wrote:
| C#? sad
|
| People literally learnt nothing at all
|
| Want to stay away from unity?
|
| You should also stay away from C# and Microsoft
|
| https://exceptionnotfound.net/the-catch-block-80-the-dotnet-...
| seneca wrote:
| Boy, there sure are a lot of pro-Godot and anti-Unity posts on HN
| today. Some marketing group is having a fieldday.
| curioussavage wrote:
| I was really tempted to try out the c# support but I opted first
| for the rust godot bindings and then the nim bindings. Nim is
| working fantastically. I was a bit worried because the bindings
| are not really actively developed but from my experience so far I
| think they just don't need much work.
| viktorcode wrote:
| > Using async and await with C#'s Task can be a bit of a headache
| with Godot, especially if you don't realize that that most ways
| of executing an async Task in C# starts a new thread (or recycles
| one from the task thread pool).
|
| Unity makes it much easier though.
| binarynate wrote:
| People are overreacting to Unity's acquisition (technically a
| merger) of ironSource and Riccitiello's comments on monetization.
| Many developers want to make money from their games, so I think
| it's positive and worthwhile for Unity to give them tools to do
| that. As for Unity's market cap, the market as a whole has taken
| a beating over the past few months. As someone who works with
| Unity and sees the enormous value it provides, it just strikes me
| as a great time to buy their stock while it's low.
| wilg wrote:
| I tend to agree, but I do really worry about Unity's technical
| roadmap. There are so many half-baked systems that rarely get
| updates, 3 confusing choices of render pipeline, and there's
| not robust well-utilized implementations of common gameplay
| elements like Unreal has.
| [deleted]
| caconym_ wrote:
| Ironsource is a malware vendor. I'm not sure in what sense you
| think people are overreacting, but I think that fact alone is
| worthy of a raised eyebrow or two. Unity has _merged with a
| malware vendor._
| marcodiego wrote:
| Some excerpts:
|
| > At first glance, Unity is so laughably ahead of Godot in sheer
| number of features supported that it seems comical to compare the
| two.
|
| > In practice, Unity requires 3rd party tools for tweens, timers,
| and networking, all of which Godot includes out-of-the-box.
| Still, I'd argue that it doesn't actually matter for the vast
| majority of us indie game developers.
| languageserver wrote:
| I miss XNA
| WorldMaker wrote:
| I do too some days. I keep meaning to do a deep dive into
| MonoGame to see where it is today and where it may be going.
| adamrezich wrote:
| MonoGame is still a thing! and many games you've heard of were
| made with it https://en.wikipedia.org/wiki/MonoGame#Games
| e4m2 wrote:
| Also FNA (https://fna-xna.github.io), which is aimed at 100%
| compatibility with existing XNA 4.0 code.
| jolexxa wrote:
| I first started learning C# and XNA before college to make a
| game for my Zune HD. That was my first exposure to OOP. Ah,
| those were the days...
| pleb_nz wrote:
| What support like for macos?
| jolexxa wrote:
| I use it on macOS and Windows, and it is lovely! I even have
| Steamworks.NET integrations working on both platforms with it.
| It can be a bit tricky to setup the `.csproj` correctly to
| resolve native dependencies, but not anything impossible.
| pleb_nz wrote:
| Thanks, can you suggest resources that would be useful in
| seeing up on macos?
| jolexxa wrote:
| If you don't mind me tooting my own horn too much, I have
| some docs about project setup in the readme for a test
| framework I made for C# Godot games. It has some notes
| about mac-specific things, since that's my primary machine.
| https://github.com/chickensoft-games/go_dot_test
|
| You can also look at the way that project itself is setup,
| and the `.csproj` files. If you need more help, feel free
| to join our Discord (link in the blog)!
| Mattish wrote:
| The problem with Godot is still it's age, and the lack of proven
| projects which many people are working on at once.
|
| Myself and plenty of others at small or above size studios would
| have to make a huge leap into Godot and hope you don't run into
| any scaling issues. Not just from a project point of view, but
| integration on the artistic side.
|
| LTS versions of Unity despite the known "un-fun" of it, are
| stable in a sense. Godot is moving fast, that isn't always a good
| thing for stability.
|
| I'd love to jump on the new shiny and fun engine! But having to
| make the definitive choice for a company to make their next
| project in? Unfortunately just isn't there yet. "It's fun as a
| dev" just isn't a compelling argument for literally everyone else
| who isn't the engineer, compared to the number of all size studio
| pumping out Unity projects(Some even being successful!).
| singhrac wrote:
| Do you think Blender overcame this challenge, or is it still a
| sticking point in the VFX industry? I know they're at very
| different levels of maturity but I'm curious if the open
| projects ended up helping with ironing out these kinks.
| nivenkos wrote:
| Blender was already a well-developed product before it was
| bought collectively (crowdsourced) and made a Free Software
| project.
| withinboredom wrote:
| Remember when fun and popular games were made by very small
| teams taking a chance? There was a particular whimsiness about
| them that I miss.
| TaupeRanger wrote:
| Those teams still exist but now they get drowned out by the
| enormous number of new games that poor into the space month
| after month.
| wilg wrote:
| Ugh, not more C#!
|
| I hope one of these projects takes off:
| https://github.com/migueldeicaza/GodotSwift
| https://github.com/kelvin13/godot-swift
|
| Excited to try Godot in a couple of years when it's more mature.
| Hopefully they can be the Blender of game engines - where it
| started rough and now is better than Maya or other alternatives.
| weberer wrote:
| Godot's default language is GDscript, which is similar to
| Python. I'd highly recommend that to new people switching to
| Godot. I think C# is just cruft for people coming from Unity
| and stuck in old habits/frameworks.
| TulliusCicero wrote:
| I tried GDScript and hated it, ended up manually porting what
| I wrote to C#. GDScript currently only has partial support
| for static typing, which makes things a much bigger pain in
| the ass. Using C# was a breath of fresh air after that.
| wilg wrote:
| Yeah, I don't want a weird scripting language like Unreal
| Blueprint or GDScript or Lua. C# beats all of those by a
| mile. I want a robust, ergonomic, high-performance,
| compiled language like Swift.
| mdbauman wrote:
| You obviously know this since you linked a Swift bindings
| project, but for others reading who may not be aware: Godot
| officially supports multiple languages ("GDScript, C#,
| VisualScript, and C++ and C via its GDNative technology"[1]),
| but other languages are supported by the community.
|
| In particular, a sibling comment mentions Kotlin. The docs[2]
| link to a project that adds Kotlin bindings
| https://github.com/utopia-rise/godot-kotlin-jvm
|
| [1]https://docs.godotengine.org/en/stable/getting_started/step_
| ...
|
| [2]https://docs.godotengine.org/en/stable/tutorials/scripting/g
| ...
| ianlevesque wrote:
| C# is really well suited to the task thanks to value types and
| structs, that gives you back control of memory that is lost in
| Java for example. It also has a lot of syntax sugar to avoid
| being too verbose and the memory safety and GC are desirable
| most of the time and can be avoided with well known tricks,
| like object pools, when performance needs are more paramount.
| overgard wrote:
| I don't know Swift very well, but I seem to recall the
| creator talking about using automatic reference counting
| instead of garbage collection as an intentional tradeoff. If
| that's still the case, I'd much rather use Swift over C# in a
| game (and I am using C# in a game!). The value types and
| structs are _very_ limited compared to classes and reference
| types.
| wilg wrote:
| Yes ARC is definitely an intentional and well-chosen
| tradeoff. Swift has real first-class value types (strings,
| collections, etc are all value types) and copy-on-write
| semantics that make it all work quite well. C# value types
| feel like they are funkily bolted on and aren't really very
| useful in practice (at least in Unity).
| wilg wrote:
| Swift is entirely designed around value types and structs,
| and has a much more predictable ARC model instead of GC for
| game programming. Plus, an upcoming feature will add Rust-
| style lifetimes for more control (https://github.com/apple/sw
| ift/blob/main/docs/OwnershipManif...).
| arcturus17 wrote:
| I've actually read so many good things about C# lately here and
| on Reddit that I plan to start learning it in the coming weeks
| (other reasons include .Net and F# being an adjacent language)
|
| What don't you like about it?
| throwaway675309 wrote:
| Do you have an actual specific disagreement with c# or are you
| just venting because you are not familiar with the language?
|
| C# is a robust language with a lot of features like lambdas
| pattern matching etc. I also find that most of the people who
| know Swift are Apple developers, so I feel like there isn't a
| broad enough appeal especially for game devs who are going to
| be more Windows or Linux centric.
| wilg wrote:
| Yes, I know C# reasonably well. I use it in Unity for game
| development, where it is the only option.
|
| C# is better than many alternatives, but Swift is simply a
| better language in every regard.
|
| C#'s GC is a constant issue for games, and it makes using
| things like LINQ nearly impossible since it does so much
| allocation. Swift is designed around automatic reference
| counting instead. C#'s structs work weirdly and are hard to
| use.
|
| Swift is so much more ergonomic. C# has added a few nice
| things lately, but it's much more verbose than Swift.
|
| Swift is also more focused on performance, and is always AOT
| compiled.
|
| Unity has had to come up with some insane things to get C# to
| work across platforms - they have their own .NET IL to C++
| compiler (https://docs.unity3d.com/Manual/IL2CPP.html) that
| doesn't always work right. They also have a SECOND custom C#
| compiler for high-performance programming (https://docs.unity
| 3d.com/Packages/com.unity.burst@0.2/manual...).
|
| I'm also very excited about Swift 6's upcoming opt-in Rust-
| like lower-level memory management which should help a ton
| for performance-critical code. (https://github.com/apple/swif
| t/blob/main/docs/OwnershipManif...)
| elabajaba wrote:
| Dotnet Core is significantly faster than the old version of
| mono that Unity is currently stuck on.
|
| They've recently announced that they're finally upgrade to
| .net core over the next couple years, so that should help
| out a lot. https://blog.unity.com/technology/unity-and-net-
| whats-next
| jayd16 wrote:
| Sounds like you mostly just don't like what Unity has
| needed to do over the years with the Mono runtime, not the
| language.
| wilg wrote:
| @jayd16 No, they have dropped the Mono runtime for many
| cases (which causes some of the problems). The language
| itself is simply much less pleasurable to program in than
| Swift, and performs worse in key areas.
| kitsunesoba wrote:
| My experience with C# has mostly been working on a personal
| project WinUI desktop app, and my biggest peeve has been
| reaching for something I use regularly in other languages
| only to find that it doesn't exist, and the solutions
| offered up by googling are usually, "well you can write
| your own implementation", "[huge utility library] offers
| that", or "don't do that it's not
| idiomatic/performant/etc". While none of those are
| showstoppers they slow development down and act as a source
| of frustration.
| Shadonototra wrote:
| C# needs a fat runtime, has a slow JIT (say hi to micro
| stutters in your gameplay and increased input latency), has a
| slow GC and worst of all is owned by Microsoft with a
| proprietary debugger that you can only use on visual studio
| (licence they changed overnight because Jetbrains released a
| C# IDE)
|
| There are much better languages for game scripting (LUA for
| example)
| overgard wrote:
| I can't speak for the grandparent, but using C# in Unity, the
| garbage collector is always at the front of mind and
| dissuades people from using some of the nicer features of C#
| (LINQ, etc.). Granted my knowledge of this is a couple years
| old, so maybe the situation has improved, but I'm guessing
| most Unity developers are still very careful about how they
| write loops and how/when objects are allocated and all that
| stuff. Automatic memory management can be more of a hindrance
| than a benefit if you have to babysit it to avoid GC pauses.
| kitsunesoba wrote:
| C# isn't the worst but out of the newer languages I've tried
| it's probably the one I'm least excited to write. Swift or
| Kotlin would definitely be preferred.
| disintegore wrote:
| > One is an industry behemoth and the world's most popular game
| engine, while the other is a free, 30 megabyte program developed
| by passionate developers in their free time.
|
| I was under the impression that Godot had at least two full-time
| devs working on it. Between their patreon revenue and the grants
| they've received they can definitely afford a small team on
| payroll. It's still important to stress the comparison in scope
| between Unity and Godot, but the latter is definitely more than a
| hobby project at this point.
| brundolf wrote:
| At least one of them, the original creator, is full-time (I
| follow him on Twitter). Not positive about others but it's
| certainly possible
| jolexxa wrote:
| That's a good point, I can edit that for clarity in the article
| (especially since I mentioned Godot's Patreon support later in
| the article). I was assuming that the Patreon support didn't
| amount to full time support for all the devs that contribute,
| but I don't know if that's true or not.
|
| Either way, it seems a lot of people have contributed without
| sponsorship, but the main devs are (hopefully) compensated.
| prox wrote:
| There are at leasts two full time devs and a handful of other
| devs on paid projects (by way of Patreon and a few large
| donations of companies like Epic)
| T-A wrote:
| I'd like to see a comparison of Godot and Stride (formerly
| Xenko):
|
| https://www.stride3d.net/
| orthoxerox wrote:
| And formerly Paradox, if I'm not mistaken. It's one of the
| worst marketed game engines I have seen. Two rebrandings and
| practically zero social media presence. People are still
| starting more new projects with XNA than with Stride.
|
| I would be promising asset compatibility with Unity and
| shouting about that everywhere if I were Stride.
| dcow wrote:
| Seriously curious to those in the gamedev community: how does
| Unity acquiring an ad company materially effect the feature set
| and platform that Unity currently provides? Is it one of those
| "Unity has been going downhill in slow-mo for years now and this
| investment is proof that they aren't interested in fixing real
| issues that indie devs have--writing's on the wall..." type of
| thing? From the outside, just seems like business as usual to
| me... I genuinely don't understand the pull people feel to
| entirely retool simply because Unity wants to do ads better. What
| am I missing?
| nitrixion wrote:
| As a dev that uses Unity on a daily basis, here is my
| perspective.
|
| If this was simply a matter of "Unity wants to do ads better"
| and they purchased an adtech company, I doubt there would be
| much discussion about it. That is not what happened. ironSource
| is not just an adtech company but a company that has built and
| distributed software that has been classified as malware by
| Sophos and Microsoft Essentials[1].
|
| While this may be an overdramatic take, once ironSource is
| fully integrated with Unity and we update to the latest LTS
| version that includes ironSource software, I expect that we
| will want to virus scan _our own executables_ built through
| Unity. I do not trust ironSource nor do I trust any software
| that integrates with it.
|
| Now, putting the malware concern aside, I also see this as a
| step in the wrong direction for Unity. There are MANY uses for
| Unity that are not games, that will never have ads, and that
| will never utilize anything from this acquisition. The concern
| here is that recent updates of Unity have made some of these
| features such that you _cannot_ disable them.
|
| To me, this is yet another poor decision by the Unity team. As
| an aside, I recently started looking into their freshly
| released new Analytics platform and it is an absolute mess of a
| release. There are massive oversights in the implementation and
| bugs that prevent workarounds to those oversights.
|
| Unity is not looking like software worth betting your company's
| future on. At best, it is looking more like prototyping
| software before using a better engine.
|
| [1] - https://en.wikipedia.org/wiki/IronSource#InstallCore
| dleslie wrote:
| As someone who has a mortgage and children to feed ... Unity
| acquiring an ad company is encouraging. For years now Unity
| seemed to be lost and directionless; having them merge with an
| ad company shows that they're serious about focusing on
| creating a product that will help developers turn a profit.
|
| But you won't hear many "indie" developers say as much, because
| making money is uncool.
|
| That said, IronSource is sketchy as hell. I'm more concerned
| about _who_ they merged with then that it was an ad company.
| yomkippur wrote:
| What if I want to create my own Roblox, how would I do that here?
| Is there a 3d engine/game engine where I can tweak the editor and
| distribute to my end users?
|
| The point is so that I can lean on the community to create the
| content and I would just focus on maintaining game servers, and
| adding moderators.
| citizenkeen wrote:
| I feel like now is a terrible time to use C# in Godot, since
| they're (AFAIK) switching from Mono in 3.X to .NET Core in 4.
|
| I love Godot and I use .NET in my day job, but I feel like C# in
| Godot has always been a second class citizen.
| _gabe_ wrote:
| What's wrong with .NET core? It's the future of .NET afaik and
| it has multiplatform support and it's open source.
|
| > .NET (Core) -- A cross-platform and open source
| implementation of .NET, rethought for the cloud age while
| remaining significantly compatible with .NET Framework. Used
| for Linux, macOS, and Windows apps.[0]
|
| [0]: https://docs.microsoft.com/en-us/dotnet/core/introduction
| adamdusty wrote:
| I think gp is saying that since it switch from mono to core
| before you will be able to finish a game, you might have a
| bad time when they switch implementations.
| eropple wrote:
| It's certainly possible that that's the case, but I've seen
| a lot of projects go from Mono to .NET Core without much of
| a hiccup, too.
|
| Probably worth pricing in some slack time to deal with it
| if it's a problem, but I struggle to think of changes from
| Mono to .NET Core which would be threatening to the ability
| to finish a project.
| 999900000999 wrote:
| >You can also use C#'s events, which are strongly typed, but if
| you need to interface with node events, you should use Godot's
| signal system.
|
| Nope. Nope. Nope. Nope, I wasted 2 hours of my life trying to get
| these signals to work in GD script.
|
| I'm going to try some other open source engines, but trying to
| jerry-rig an extra language on top of a relatively immature
| engine isn't a very good idea.
|
| Now I imagine if Microsoft decided to come out of an engine, they
| could rationalize supporting six or seven languages. But if
| you're already a small project, what ends up happening is the
| other language support just isn't as good
| cain wrote:
| What issues did you have with GDscript's signals? I've been
| using Godot for > 2 years and had no issues with them.
| nchi3 wrote:
| What didn't work for you? I remember thinking events were
| surprisingly easy to use with GDScript when I tried the Godot 4
| alpha earlier this year.
| 999900000999 wrote:
| Compared to Get component with Unity, sending messages isn't
| all that great.
|
| I'm looking at some other OSS engines now
| dimgl wrote:
| What? This is not at all what the author is describing (or
| even what you're insinuating is bad in Godot).
| bj-rn wrote:
| Check out https://github.com/stride3d/stride
|
| It's MIT and fully written in C#.
| overgard wrote:
| As much as I'd like to use Godot, there are two features missing
| that I really don't think I could do without:
|
| - Asset store. I totally get it, handling payments, curating,
| etc. are a huge task... but man, I'm a coder, and I don't have
| the funds to pay an artist or a musician full time. Being able to
| just go buy a pack of trees for $20 or something is a huge timer
| saver.
|
| - Animation re-targeting. It seems like there's a 3rd party
| plugin for this but it also seems like it hasn't been updated in
| a year. In unity I can buy a big pack of animations for pretty
| cheap and reuse it on almost all my humanoid characters. That's
| huge. I think this can be done in Blender or Maya, but it's so
| seamless in the engine compared to using a 3rd party tool.
| to-too-two wrote:
| "Animation re-targeting."
|
| Yeah, that'd be cool. However, there are tools like Mixamo by
| Adobe that provide lots of pre-made animations.
|
| As for an asset store for paid assets, there are already a few
| 3rd party sites for this.
| wly_cdgr wrote:
| If you're just talking about some models or sprites, can't you
| just buy them wherever in any file format Godot supports and
| import them? Ok, you might have to spend a bit of time wrapping
| them in Godot's nodes, but it seems like that would be quick
| and trivial
| TulliusCicero wrote:
| Okay, and is there an ecosystem that makes it trivial to
| find, buy and import such assets? How big and well designed
| is that store?
|
| "You can technically do the same thing if you squint" misses
| the point.
| giancarlostoro wrote:
| > - Asset store. I totally get it, handling payments, curating,
| etc. are a huge task... but man, I'm a coder, and I don't have
| the funds to pay an artist or a musician full time. Being able
| to just go buy a pack of trees for $20 or something is a huge
| timer saver.
|
| Heh I mentioned this in another Godot thread a few days ago. It
| sounds like a potential YC funded startup for anyone inclined
| and something that could be with the knowledge and
| collaboration of the core maintainers of Godot as a simple
| means to fund Godot.
| sergiotapia wrote:
| This doesn't sound like a good VC backed company. Bootstrap
| it, make healthy profits and grow at a normal pace.
| to-too-two wrote:
| There's a few private/third-party sties that serve as a
| marketplace for paid Godot assets.
| TulliusCicero wrote:
| It seems unlikely that'll ever be as useful to people as an
| official store would be.
| ttymck wrote:
| Why is that? (I'm not too familiar with Godot or the
| unity asset store)
| to-too-two wrote:
| Mostly trust. Finding it. Usually lacks the polish and
| presentation an official asset store would have.
|
| Unity's asset store is pretty top-notch and is a good one
| to compare other asset stores too. Unreal Engine's
| marketplace pales in comparison.
|
| Link: https://assetstore.unity.com/
| to-too-two wrote:
| Agreed for the most part, although there is the
| possibility of one being really polished and catching on.
| wkirby wrote:
| I've been using Godot for hobby projects on-and-off for a while
| now, and overall I vastly prefer it to Unity. The scene hierarchy
| of Godot is a better mental model (for me) than the
| GameObject/MonoBehavior ever was.
|
| That said, I have a _few_ items that I think are absolute
| showstoppers for solo-dev side projects.
|
| 1. The asset pipeline is simply not as clean as Unity's. The
| ability to drop a .blend file in the project in Unity is so
| underrated. In Godot FBX imports are unreliable, texture imports
| misbehave frequently, and rigging goes wrong even in the
| recommended file formats. There's a lot less clarity around the
| path to getting real assets in game, which can be a major pain
| point for solo devs.
|
| 2. Along the same lines, there is no equivalent of Unity's
| mecanim. With Unity, if you can model and rig a character in
| Blender, you can pull free mocap or other animations from the
| asset store and get to work. In Godot you're still best off
| authoring your own animations for each character. This
| drastically increases the amount of time spent making assets.
|
| 3. Godot is in a weird spot version wise for anyone who wants to
| use C#; the beta version of 4.0 is rapidly approaching, and
| guarantees to break any project you start in 3.x --- but 4.0
| still doesn't come built with C# support. Hopefully this gets
| resolved soon.
| didibus wrote:
| I'd also recommend people check out Defold: https://defold.com/
|
| I'm not a game dev, but its the engine King uses that they
| completely open sourced, and I think it can be a good
| alternative.
| mdaniel wrote:
| Maybe that's typical in gaming situations, but it has a weird
| license:
| https://github.com/defold/defold/blob/1.3.4/LICENSE.txt ("the
| Defold License version 1.0")
| aikah wrote:
| Yes indeed, it's time to move from Unity to something else
| because I don't want to pay for that kind of people's salary:
|
| > Devs not baking monetisation into the creative process are
| "fucking idiots", says Unity's John Riccitiello
|
| https://mobilegamer.biz/devs-not-baking-monetisation-into-th...
|
| If he talks in public like that, imagine how this guy talks to
| his employees behind closed doors...
| hertzrat wrote:
| > I've seen great games fail because they tuned their
| compulsion loop to two minutes when it should have been an
| hour.
|
| Nobody tries to hide anymore that a lot of game companies just
| create skinner boxes
| Kiro wrote:
| The HN thread about the quote:
| https://news.ycombinator.com/item?id=32097752
| BoorishBears wrote:
| He didn't say that.
|
| "mobilegamer.biz" is betting on you not reading before getting
| outraged, and it looks like that paid off.
| dwallin wrote:
| To be fair, the full comment is even more belittling than the
| sound bite. It's almost dripping with contempt for those who
| have a different set of values than him.
| BoorishBears wrote:
| It's ironic you say that because as someone who arguable
| fits in the category he's talking about (see: my bleeding
| heart comments about Unity's for-profit asset store from
| yesterday) it feels somewhere between belittling and
| insulting for people to act like grown adults would really
| miss what his point was.
|
| There seems to be this "rainman-esque" infantilization of
| people who put craft before profit that I truly deeply
| hate. He spoke like he was having a frank, open,
| conversation. That relies on everyone involved being
| somewhat mature and not jumping to the worst possible
| interpretation of everything.
|
| But I don't know, maybe people are right to treat "the
| creatives" with the kiddie gloves based on the reaction
| I've seen.
| jibe wrote:
| Full quote for context:
|
| _Riccitiello: Ferrari and some of the other high-end car
| manufacturers still use clay and carving knives. It's a very
| small portion of the gaming industry that works that way, and
| some of these people are my favourite people in the world to
| fight with - they're the most beautiful and pure, brilliant
| people. They're also some of the biggest fucking idiots._
| dmitriid wrote:
| Full quote doesn't make it better in the least
| nnq wrote:
| At least appreciate his honesty - it's way better for
| everyone to be so blunt about it.
| amatecha wrote:
| Full interview is at
| https://www.pocketgamer.biz/interview/79190/unity-
| ironsource...
| [deleted]
| edmcnulty101 wrote:
| I googled a picture of him and he seems like he smirks a lot.
|
| He also is being sued for sexual harassment...shocker.
| yomkippur wrote:
| Or calling developers "code monkey" like in Vancouver
___________________________________________________________________
(page generated 2022-07-14 23:00 UTC)