Hexbear gamedevs unite!
I was mostly doing this https://gdquest.github.io/learn-gdscript/
Oh word, do you write any other languages? Side comment: I had no idea this thing existed, it's really fucking well made 😲
I totally fuck with it! I finished the default tutorial ages ago then spent a bunch of time tweaking it to have a bigger map and some QOL features, right now I'm working through this Action RPG Tutorial and I've got kind of vague Zelda-like idea I want to work on in earnest after that.
HeartBeast's tutorials are pretty solid, I went through them myself, too.
If you ever need help with the engine, you should totally shoot me a message!
I fucked with it a bit a long time ago! I love how much that thing has been able to accomplish in such a short time while being open source.
Mostly fiddle with my own engine as a hobby these days, though. Was using Unity like 7 years ago, got pissed off enough to roll my own thing, and now my fun is just tinkering haha.
It is! I did build it on top of a very mature framework though (MonoGame).
I'm actually just now starting up work on a little game I'm making in the engine. Maybe I'll share it here when I'm further along!
It's fucking nuts. Ever since I was in the fifth grade I wanted to re-invent the wheel and build a game engine from scratch. There are so many moving parts and disciplines involved. Eventually I came around and figured it's not worth it (mostly due to the initial libre release of Godot). Jason Gregory's Game Engine Architecture is an incredibly detailed high level overview of what is involved in making a modern game engine (by 2009 standards, but still largely applicable).
This is kind of where I've landed. Years ago I fucked around with XNA - at the time I didn't understand the difference between an engine and a framework, and I wasted so much time just building shit to accomplish other shit so that I could eventually design game. I actually want to make -game-, not game engine.
I've messed with the tutorials a bit but haven't made anything yet. Is it worth waiting for version 4.0 to come out?
I've been using it since 3.2, people seem to be very excited for 4.0, but I don't see any point in waiting? If you have something in mind that you want to make, then it'll only be benefited by 4.0's release, but you'll be months behind if you wait vs. if you start now. Version 3.+ has been able to meet every demand I've thrown at it so far, so I don't see why it shouldn't be used
Cool, I've been seeing a lot of the "wait for 4.0" talk so I was apprehensive about starting anything
Same, I don't really get it personally. I guess 4.0's release may be just around the corner though, so maybe it's a moot point
The worst part of Godot is the designers want people to pronounce it in a French voice. I WILL pronounce it Go Dot, I WILL NOT say Gah Dough.
Is it for sure getting full C# support? Things I've read seemed to indicate that C# implementation is sort of up in the air?
Oh word, that's excellent! Why not get started with the betas?
I currently have no ideas for games that require a 3d renderer + no free time to work on one. If I did, I would definitely try out Godot 4 though.
Word, this is probably redundant to say, it seems like you have some familiarity with the engine, but Godot's 2D solutions are really good too!
My current game-in-progress is a idle browser game, written in Blazor. So no renderer needed at the moment :)
From my understanding, the workflow for 2D in Godot is superior to any major commercial game engine that doesn't focus specifically on 2D (so like, all of them with the possible exception of Gamemaker Studio which I remember being very easy to use and fly with back in 2004). What's missing is the massive asset libraries, prefabs, and plugins. If your game relies on any moderately complex dynamics, you're going to have to figure that out on your own. That said, I don't live and breath gamedev so I may have some blindspots.
A little bit. I never got too far with it, but I did a few experiments. It doesn't get showcased very much in the examples, but there is a lot you can do to extend the editor using GDScript to make all sorts of domain-specific tools. If you need some kind of height-map editor, procedurally generated geometry, or other forms of visual feedback, you can flag your scripts with the
toolkeyword and they will run live in the editor. The editor itself is designed fully with the same GUI system used by Godot games, so the sky is the limit here. For a little while I was working on creating 'scenes' to produce procedually generated geometric primitives. The only proof of concept I created was a cylinder where you could enter the radius, height, and number of sides, but it would take those inputs, compute a mesh, and it worked and updated live in in the editor when you dragged the sliders around.The C++ codebase is fairly approachable for a project of Godot's size, and without too much elbowgrease it is possible to create new types of nodes which can be used throughout your game.
The last thing I worked on was a sort of trial in creating data-driven game objects and an interface where the user could attach them together arbitrarily. The long-term goal (which I will never get around to) was a libre clone of Kerbal Space Program and I was seeing if I could design a similar part/assembly system. for this test, everything (all three parts) were just 2D sprites and all you could do was snap them together.
Anyway, I highly recommend the engine. The 2D graphics are state of the art, and the 3D graphics are sufficient for any indy game. The editor works on all of the important operating systems (Linux and BSD :garf-troll:), and the games will run on browsers, PCs (including MacOS), smartphones, and video game consoles (after taking performance and resource limitations into account, of course). The video game consoles and iOS obviously will require some proprietary shit which is not included though. For the most part, all the file formats created by Godot are designed to work well with revision control systems such as Git.
A major point for me was being able to export my game to linux. So, huge +1 for Godot in that respect.
It's software for creating video games! It facilitates a lot of the difficult stuff involved in getting things to move and make noise on screen. Allows one to 'drag-and-drop' objects into scenes together and like, get them to interact with each other.
I guess more broadly it can be used to create software in general, but it's bent toward making game design fast and easy.
It's super cool that Godot is becoming popular. Dome Keeper got a great reception recently, and obviously Cruelty Squad was a hit.
I might have to get into this sometime. I always have analysis paralysis when it comes to working in game engines.
I'm habitual game designer though. I've amassed a bit over 150 game design documents that I've written in that time. I don't just want to be the ideas guy though as much as I love doing that and thinking systematically. Maybe one day I'll actually make one.
:joker-gaming:
For as much as people have historically shat on the "ideas guy", if your design docs are comprehensive, I think that shit is incredibly useful and valuable. You might find that your wealth of forethought can be transformed into a game incredibly easily (at least until it comes time to graduate from placeholder art and assets to production)
Thanks! I appreciate that. I've learned a lot about game dev at a high level just out of sheer curiosity. I guess it's the systems focus I have because I know how they interact with one another and can carry on a conversation about some things, but not how to open an IDE and actually make it happen.
I think a lot of the bad rep the "ideas guy" gets is for having an incredibly massive idea that's wildly out of scope without considering achievability. Just looking at the game ideas sub on :reddit-logo:, I didn't even have to scroll to come across an idea of a "real time, FPS military game, where every bullet and car is player crafted, and there are thousands of players playing simultaneously, and also the entire map has no instancing." I try to keep my ideas tightly scoped and avoid adding mechanics unless it's really necessary to the core gameplay.
Yeah, I think you've really set yourself and your work aside from the typical 'ideas guy' stuff. Most folks don't contemplate things that far.
feel free to message me if you want advice or assistance with it!
It's as easy as game making gets, with the exception of RPGmaker. It's basically the open source replacement for GameMaker.
It's not hard, but I think with any gamedev effort, eventually you're going to reach a point where you need to learn to write some script. Personally I found GDScript really easy to learn, but I had already known a few other languages beforehand. If you already know how to code a little bit, I think it's a pretty damn easy engine to work with.
Would like to. This thing looks rather versatile for 2D or 3D. And have a reputation of being beginner friendly.
But since I can barely finish a game with a more limited scope(mostly text + limited art) and play to my strength(javascript instead of godot's proprietary language, which have load-bearing indentation like python, why is this a popular trend?), it's on the back burner.
It supports C# also, so you should be able to translate your javascript experience over to that fairly easily?
Did the YouTube tutorials for a sample game. Then I wanted to make a turn based RPG but then got lost cuz I don't know what my first step would even be and just got busy with irl
You might think that designing something turn-based would be pretty simple, but it's tricky when you actually try to approach it, right?
I like godot because the editor is real small and loads quickly. I do not have the strength of will to sit still and watch a loading bar while unity defrosts
I installed in a month back and played around a little, but nothing since. This is a good reminder to go back to it though!
