Comment by karim79 | Hacker News Reader

Comment by karim79 | Hacker News Reader

Regardless of how far we've come with game engines and dev kits, RAD tools, open-source engines which deal in 2D/3D, sound and music creation frameworks etc etc, I can't help but admire the hell out of the people who can actually sit down and get something done properly and even go further to tutorialise it.

I've sat through a few game development tutorials - mostly Unity and Godot ones, because one day I'd love to create the game which puts the Monkey Island series to shame.

Upon witnessing how much work it is to actually get something to happen in a single scene, to get things to behave in a non-broken way using one of these engines, I'm not sure I'll ever have the patience to get there. I don't imagine having much of a problem coding the game logic (character says "Yes" door unlocks and becomes interactable etc) but having everything from the art style, scenes, sprites, and applying it all in a non-sucky, tasteful way? That's high art.

And yet game devs are inexplicably being fired like there's no tomorrow. No justice, I say. None whatsoever.

I think your chosen genre is among the easier ones to get things to work. If you had good artists at your disposal, you could fairly easily build a clone of the classic Monkey Island on a modern engine.

Great artwork feels like something impossible to deliver, but artists think exactly the same about code. I say this after witnessing how quickly one of my friends creates great looking art while being impressed by some trivially easy programming feats.

I'm not knowledgeable about that specific subgenre, but if you're going to be more or less following the traditional rules of older graphic adventures, I think there are plugins for Unity/Godot that automate most of the common stuff and you can focus on the art and game logic, dialogue, etc. So instead of trying to learn how to develop games, try to look for specific tools to develop graphic adventures, you might find that part of the boring hard work is avoidable!

You could probably build your own library in SDL2 and get it done quicker and have a solid framework for pumping out games going forward.

I would use an engine for 3D, but not 2D. For 2D work an engine like Godot is like trying to use a no-code platform to build apps, you end up with a bespoke and unmaintainable hindrance when you could have just built yourself a good foundation from scratch with slightly less effort. Leverage Copilot to get you up to speed with the boilerplate.

You absolutely could not get it done quicker or with less effort using SDL2. 2D games are deceptively complex beyond trivial examples, and most of your effort would be wasted on poor and ad-hoc reimplemetation of features that an engine already takes care of. If you want to finish a game, use an engine. If you can't finish a game with an engine, you'll never finish one without an engine, because without an engine it's exponentially more difficult.

And the premise that a project within an engine is a "bespoke and unmaintainable hindrance" as opposed to a pile of raw AI generated code is simply laughable. If you're going to use Copilot anyway, why not also use an engine? It's obvious at that point you care less about code and code quality than getting a product finished as quickly as possible.

I don't know, I managed to complete a few games, one with SDL2 and a few with libgdx. But could never complete anything with a "GUI engine" (don't know what the terminology is) like Godot or Unity.

When everything is code, it "makes sense". You have a main loop, you can reason about what is happening when. You can set a breakpoint and walk through everything step by step.

I have no idea what's going on in Unity or Godot. Everything is completely unfamiliar, there are a bunch of abstractions I'm unfamiliar with and I can't rely on any of my past experience. I'm basically starting from scratch.

If I was tasked with making a game quickly, I could probably do it faster in SDL or Libgdx (if that's still around) than I could learn unity or Godot.

Yes, you do have to actually learn how to use an engine, just as you had to learn how to use SDL or any other library. Most people, once they learn how to use such engines, are far more productive than people writing entirely low-level code. You can have a basic 2D or 3D scene ready in Godot in minutes, with collision detection, lighting, camera and a controllable player. from scratch, the equivalent of either might take days or weeks.

I'm not disparaging low-level coding here, I write projects in C, LuaJIT and SDL myself. But I know from personal experience how liberating it can be to not have to deal with 90% of what amounts to uninteresting boilerplate and focus on the actual creative part of a project.

Your comment reminds me of when I participated in a game jam one time irl. A lot of other people were using existing engines and there were some pretty cool results that different groups had.

I worked alone and used SDL. This was also one of my first attempts at making a game.

I managed to make a couple of command line inputs and outputs in the terminal, and then use SDL to render a single sprite on screen that did not move or anything. Needless to say, my entry did not win any prices :p

Triggered.

How appropriate, you fight like a cow.

How appropriate, you fight like a dairy farmer.

I mean if you want to actually make a monkey island like game you could try using Adventure Game Studio, which is made to make games like that.

Reply on news.ycombinator.com