5 ms·

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 indi

• dgb23 6y ago
  I'm looking forward of what becomes of the Jai programming language.
  • _bxg1 6y ago
    It looks well and good, but the point remains that it won't help you build for consoles out of the box.
    • m0shen 6y ago
      It apparently already builds for Switch: https://www.reddit.com/r/NintendoSwitch/comments/cixsoy/jonathan_blows_jai_game_programming_language_now/ https://www.reddit.com/r/NintendoSwitch/comments/cixsoy/jona...
      • _bxg1 6y ago
        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.
        • dgb23 6y ago
          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.
          • _bxg1 6y ago
            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.
  • cableshaft 6y ago
    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.
• dx87 6y ago
  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/ http://www.lonewolftechnology.com/
  • _bxg1 6y ago
    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.
• ohgodplsno 6y ago
  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/consoles.html 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.
  • _bxg1 6y ago
    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.
    • ohgodplsno 6y ago
      >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.
      • rr_aa 6y ago
        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.
        • pjmlp 6y ago
          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.
• reedwolf 6y ago
  Pygame?
• machisuji 6y ago
  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.
  • username90 6y ago
    How much C++ you need depends on what kind of game you are making. You probably wont make a game like Civilization in blueprints.
    • TeMPOraL 6y ago
      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.
• cableshaft 6y ago
  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/ https://www.monogame.net/showcase/
  • disease 6y ago
    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.
    • cableshaft 6y ago
      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).
• michaelbrave 6y ago
  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.
• deleted 6y ago
  [deleted]
• georgeecollins 6y ago
  >> 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.
• fzeroracer 6y ago
  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.