Godot Game Engine – Getting Started | Hacker News Reader

Godot Game Engine – Getting Started

sandromaglione.com

33 pointslassmaglio10 comments

I’d love to make a game, and attempted to make a start with something simple like Unity and Godot. For me it felt like implementing simple things that basically every game has (clicking and dragging objects, or moving a player character with arrow buttons, collisions) required a lot of coding straight up. Rather than boilerplate code blocks or something. It’s not like I expect there to be no code,I expected to use code to explain to the game engine complex ideas/systems, not figure out how to do the things that almost every game has. I’m sure there are inflexible No Code game engines but is there something in between?

I’ve been working as a hobbyist in unity for years, mainly just to keep up on c# because I have no practical application for it.

I have no problem whipping out anything simple like what you mentioned in a couple of minutes, but it does strike me as odd that there isn’t a way to just plug together. Like a good example is a lot of the water physics plugins. Do I want to spend a ton of time making a water physics and visuals engine? No. But, I have to attach this random object to my character controller so that it makes a splash when it touches the water, and another to make it float. Why not just code it so it interacts with a rigidbody?

I have a character model that runs, jumps, and shoots all using a single script and the concept of a rigidbody, but I have to add arbitrary handlers to make the rigidbody capable of touching water? Why not an arbitrary script that makes a rigidbody not touch water, if I eventually want that?

Perhaps the best way to get started in the rather complicated world of game design is to make a mod. That is start with an already completed game and modify it to your will.

These game engines should probably provide something like this. Something like here is "Generic FPS" the game sucks, but it is a complete game with all the moving parts plumbed and licensed that you are free to use it as a base for any game.

A free rant on engines.

A game engine is roughly the same thing as a web framework, that is, it is an outer support layer with well defined exit points and you have to provide the business logic yourself. This works in conjunction with libraries which are inner support layers with well defined entry points and you have to provide the business logic yourself. I always preferred the term engine more than framework and always wondered why it was only used for games.

I partially blame modern game APIs such as DirectX12/Vulkan. Note that I am not saying these APIs are bad, just that the “programmable” part has no default, leaving it up to the developer to figure things out.

There was a time when you didn’t need to know what a shader was to build a game engine/game. The fixed function pipeline was super simple. Limited, but simple.

Vulkan and DirectX 12 made things even more complicated because they wanted to have better multithreaded support.

Engines try to bridge the gap between the APIs and games, but they end up creating an entire set of new things (like “scenes” and “nodes”) or entire new languages (like gdscript) that you have to learn. (yes I am aware that Godot supports multiple languages)

These days I probably use monogame the most. It seems to provide just enough to make things “easy” for me without introducing a ton of new stuff as a learning curve. Outside of that, OpenGL still exists, and you can probably find some basic shaders should have have no desire to learn all about pixel/vertex/whatever shaders.

…or maybe I am just old and cranky and miss the good ole days.

I'm curious what games you made without the concept of a scene or node.. at least from an code organisation standpoint.

I used to try and write GLES games back in C++98 out of highschool. I find modern engines much quicker and easier to understand and use

Nothing you can find these days. I seldom released my work.

I made a partial clone of the Warcraft 2 game that could load assets from the original game. It used the Windows GDI and native win32 APIs for everything. It was written in C. No classes, much less 'nodes' and 'scenes' and such. It used no code from other projects. I used available documentation and a hex editor to understand the different file formats. The first time you ran the game, it would extract the assets and convert them into something easier to read/write. The only limitation is that it did not have AI and none of the scenarios worked. You could absolutely load up any PUD, however, and move units around. If I would have added networking support, you could have battled it out, since the mechanics were in place.

I also had an MMORPG I was working on, but never finished. Client and Server cores were working great. The server was written in C++ (due to some COM components and other libs) and the client was C/OpenGL. I never finished it due to joining a startup and having no time to invest into it.

I also built a voxel engine in OpenGL. It was still in a very primitive state, however.

There were some other projects, some of which were sent to friends.

If I can find where these old projects are stored, I may open source them at some point. I also have non gaming projects I'd like to release, including a shareware project I made.

The classic “the gorilla and the entire jungle” problem

If you want the 'good old days' you can just take an old computer, emulator or 'simple' game engine which just exposes a few drawing primitives.

Vulkan or DirectX are made for current high-performance applications. Not stuff you put together on a sunday afternoon. They reflect the capabilities of today's hardware and therefore are complicated.

Engines like Godot expose some new concepts, but those are really not very complicated. You'll probably invent them on your own before finishing your first game. And then discover Godot developers did a better job after years of iterating.

But not every game does have those, which is why they must be coded. How else does the system be flexible enough to make either a 3d fps or a Bejeweled puzzle game from the same API?

I generally agree with you btw, but I think it's just a matter of course.

I tried gdevelop before and I think it's the closest thing to what you might be looking for. You can make a sprite, then give it the "player movement behaviour", get a box and give it the "mouse draggable" behaviour. Etc.

Love2D is perfect, none of the up front complexity that you have to deal with when using off the shelf engines, and you can easily progressively build up your game complexity

Reply on news.ycombinator.com