Hacker News Reader

Comment by _bxg1 | Hacker News Reader

I'm so frustrated that Unity and Unreal are the only two real options. And it's all because of console vendors.

Unreal is just way too inaccessible, as an individual, non-C++-veteran (used it a bunch in college, but modern C++ looks nothing like what I've seen), non-games-industry-veteran. It's also fairly opinionated towards first person/third person action games.

And then Unity is of course a dumpster fire. It's much easier to get started and hack something together with, but you'll be hacking and fighting with the engine for the entire project.

Open-source libraries/engines exist, like Godot, but none of them properly support consoles because console APIs are apparently proprietary (??) because the console vendors are apparently stuck in backwards, draconian software practices from 2002.

The whole state of indie-accessible tooling is just deeply depressing.

View on HN

While it might not be a good fit for a some people, Monogame is still active, still ports to most systems, and it's totally free. I ported my old XNA/Xbox 360 game to that pretty much in one night (since it's based on XNA) and have been working on remaking it for desktop/mobile/eventually console.

It's still being used for some pretty mainstream Indie games, like just-released Streets of Rage 4, Flinthook, Celeste, Bastion, Fez, Axiom Verge, Stardew Valley, TowerFall, etc.

Doesn't have all the mess or constantly moving target that everything else has, either. I mean it changed so little from XNA 4 that I could easily port a game designed for Xbox 360 over to it (shaders and storage took some extra time).

https://www.monogame.net/showcase/

That's an extremely impressive list of titles.

As a hobbyist game dev I'm looking at moving to a multi-platform 2D game engine (last few games were done for the web using Phaser). The two engines that seem interesting are Monogame and Godot. My limited understanding is that you get more tooling and ready-made things with Godot compared to Monogame. I'll have to do another deep dive of these two engines soon.

Godot looks impressive too from a casual look into it, and is also free, and definitely has more included. Monogame is more of a framework rather than a toolset, except for a Content Pipeline tool you're going to be writing just about everything in code.

Monogame has the advantage that it has been used for commercial games, so you can get a good feel of what it can handle. Most of what I've seen showcased from Godot are more toy games, not really commercial. Now granted someone has to be the first to do it on Godot, but part of the reason you don't see it might be because it has some limitations you'll run into (but probably won't as a hobbyist developer).

XNA also had a really large community at the time, and a lot of questions you have with Monogame, if you can't find the answer noromally, you can just look up the answers to for XNA and it will be the same answer, so there's a good amount of history to reference there as well.

The important thing is just to pick something and start. After XNA died out, there was several years where I didn't make any progress because I kept going back and forth on what platform or tools I should use. I do recommend picking something open source and free, though, because I've had games get stuck on old proprietary platforms in the past and have had to port them to other platforms (i.e. Flash, Cocos2d iOS).

Interesting, I remember messing around with XDA years ago when MS was making a huge push for it (before Unity was fit for anything but prototyping). It was a reasonably pleasant experience.

Does it support 3D? I don't remember whether that was the case back then.

Edit: There's a 3D game right on its home page :)

Monogame is really nice as a hobbyist.

I also like that you actually have near full control of what is happening, rather than poking at a black box engine and hoping the bits you plug into it work correctly. Of course, I'm of the age where you had to write your own Windows message loop and wrangle OpenGL or DirectX yourself to do much of anything.

It all depends on what you're planning to do. Godot is a fantastic engine for 2D stuff, with the ability to publish pretty much anywhere. And it does support consoles, in a way: https://docs.godotengine.org/en/latest/tutorials/platform/co.... It's not cheap, I agree with that.

I'm surprised at the idea that Unreal is inaccessible though. Especially as an indie, UE4's blueprint system will do absolutely anything you need to do. And, for extending the editor itself, Python is available.

I'm a programmer, who feels most comfortable writing code, so that was the route I took, and that route ended up being inaccessible. I've also heard that you can't really do everything for an entire game in just blueprints.

Unity's C# scripts on the other hand - despite all of the engine's problems - are incredibly straightforward to write, set up tooling for, build, plug into a project, and you can use them to control everything from game logic to the editor to the rendering pipeline. This is Unity's greatest strength, IMO.

>I've also heard that you can't really do everything for an entire game in just blueprints.

I wouldn't do networking in blueprints. But for your core gameplay ? It can absolutely do anything you want.

You can do anything you want if you are into managing a huge spaghetti node system. Sometimes its more efficient and especially flexible to be able to write code, and easier to maintain, update and edit.

Same would happen with code if best practices aren't taken into account.

Blueprints provides the tooling to package stuff into re-usable components, exactly to avoid spaghetti code, just like in most graphical programming languages.

Godot is also great for 3D, and increasingly so. We're already making great VR games with it, and it's only going to get better with Godot 4.0 which will support Vulkan (to be released this summer).

I've switched from Unity ~7 months ago and never looked back.

Curious - is your team using GDScript, C#, or C++ primarily? It seems like GDScript is still the happy path for compatibility, but I have mixed feelings about it as a language (though I've written enough Python to be relatively productive in it in my little Godot experiments).

We're using GDScript and like it a lot. I find that I'm much faster than with C# and haven't had any performance issues yet. The good thing is that you can mix and match languages as you like. So you could write 99% in GDScript and there's something where you really need performance just write it in C++, Rust, Python or any other language you want.

It looks like that they're re-working GDScript for 4.0, so that'll get a lot better, too.

I've used Unity and Unreal Engine 4 for a while I don't think i'll want to switch from UE4 for 3D based things i'm pretty excited for Godot 4.0 and all the new nifty features I've been hearing about.

Does it make sense to hold off diving into Godot until 4.0 (for 2D-based things) or will there not be too much to "relearn"?

I'm not a contributor to Godot, but my understanding is that Godot 3.x projects will be mostly compatible with Godot 4.0, and where conversion is needed they will provide tools.

Therefore, I assume that the fundamentals of Godot will stay the same and you should be fine diving in with 3.0 already :-)

Has anyone ported to a console? The wording here is a bit confusing, I thought they meant you have to pay a 3rd party to port your whole game (from scratch?) but maybe it means they'll have to compile a special version of the engine for you instead with the devkit or something?

It's the latter. A third party provides you with the stuff you need to export to consoles, e.g. export template(s) and such that for legal reasons can't be included in the normal version of Godot. Here's a recent thread about having a Godot game built for Switch: https://twitter.com/monolithofminds/status/12599133551769272...

Perhaps somewhat ironically, I've started feeling like Game Maker Studio is a far better choice if you're looking to make a strictly 2d game. Despite being someone who works primarily in C#, I try to avoid Unity like the plague nowadays for all of the other reasons outlined in the thread.

Unity keeps rebuilding the core foundation of the engine which means at any point the work you did could be invalidated. So now everyone's operating on a different version of the engine, trying to solve bugs related specifically to that version and it means if you actually need something from a later one you're SOL.

Whenever I've worked w/ Unity I've felt like I spend more of my time struggling with tooling than actually making a game. From a more skeptical point of view I understand why: It's because it means they can create a marketspace where you have to buy additional tools to make game creation more robust. From a developer point of view though, it results in a nightmare.

I was always ruling out Unreal as an option due to C++ because I'm no good with C++ and it seems scary.

But in the end I got so frustrated with Unity that we did do the switch to Unreal. So far I actually had to do a lot less coding in Unreal than in Unity. There's almost nothing you can't do in blueprints.

The only thing I had to write C++ for is some JSON parsing because the existing JSON blueprint libraries (from the marketplace) are terribly slow. What little C++ I had to write is fairly simple. Just using core APIs form Unreal itself (FJsonObject). It's just creating structs and calling APIs. Easy enough even for me.

Everything else we implement in Blueprints. No C++ required.

How much C++ you need depends on what kind of game you are making. You probably wont make a game like Civilization in blueprints.

Which Civilization?

I'd say a lot depends on how much stuff you're doing every frame. From what I've seen, Epic is emphasizing you should avoid running blueprints every tick, and instead use event-driven programming heavily (or "steal" ticks from input handling), and then flip appropriate switches to remove anything that doesn't need updating every frame from even being issued a tick by the engine.

>> The whole state of indie-accessible tooling is just deeply depressing.

This is by far the best it has ever been in my 25 years in the game business. If you are daunted by making a game in Unity or Unreal today, you would be without hope twenty years ago.

I'm looking forward of what becomes of the Jai programming language.

It looks well and good, but the point remains that it won't help you build for consoles out of the box.

It apparently already builds for Switch: https://www.reddit.com/r/NintendoSwitch/comments/cixsoy/jona...

Let me clarify: Unity gives you high-level APIs for things like graphics, audio, input, networking, that work across all supported platforms automatically. There may be some platform-specific quirks, but roughly speaking, you can just click "build for X" and get a working X build. There's a huge gap between compilation and that.

I don’t know how Jai will do this. But my gut feeling says that the meta programming capabilities will could help doing this sort of thing. My understanding is that it enables one to say „build my program in this particular way“ expressed within Jai itself.

Please correct me if I‘m completely off.

I honestly think this is outside the scope of a language; it's really a library/framework/toolset thing. I'm sure it will be possible to do this with Jai (maybe it already is), but you'd still have to do it with Jai as opposed to Jai doing it.

I'd love for there to be some way to start experimenting with it. I understand it still has a long ways to go, but I'd like to get more of a feel for it outside of Jonathan Blow's 4 hour+ work sessions on Youtube.

I understand the likely reason why he isn't, because he doesn't want to have people bugging him for support on it, but if I could sign a "I promise not to email you any questions about it and I'm using this at my own risk, pinky swear" and get access to download the latest version of it, I would.

For Godot, there are actually some companies that you can work with who will make your game playable on consoles[1]. It's a pain that it has to be done that way, and the devs said it isn't a trivial amount of work, but I remember seeing at least one game on /r/godot that was launching on PC and Switch.

[1]http://www.lonewolftechnology.com/

Yeah. Sounds expensive though, which makes it a tough sell for many indies. Maybe if your game makes it big on PC first that could make sense, but that won't apply to everyone.

I saw something the other day about using godot with the switch, it's more of a licensing problem than a technology one and there is a way to do it.

Pygame?

Reply on news.ycombinator.com