Don't make your own game engine [video] | Hacker News Reader

Don't make your own game engine [video]

youtube.com

21 pointssurprisetalk15 comments

The speakers suggest that people:

1. Choose a game design to build by copying an existing game loop in a game you like.

2. Build everything you need to make that game.

The "don't make your own game engine" advice applies to not falling into the trap of building a generic game engine before step 1 or 2 — just build the game itself and your "engine" is everything that's needed for that one game.

Oogabooga seems to be their Windows-only set of C libs (including a replacement for the C standard library and a build system) to help people build Windows games, and seems focussed on top-down 2D games. https://github.com/alpinestudios/oogabooga. They intend you to fork the repo and use that as the starting point for your game.

They also mentioned that it includes hot reloading but I don't see anything about that in the docs or repo. It looks like there's a free group that might have a more guided walkthrough here but it's gated behind a sign-up: https://www.skool.com/game-dev/about

Since people are making assumptions based on the title: The video is stating that if you're making a game from scratch, you shouldn't make a game engine. Instead, you should focus on what you need to implement for your game specifically, and make that. I didn't listen beyond that point so I might be missing more, but it's not saying "use off the shelf game engines."

When I started as a game developer making your own engine was required. In fact I was at the meetings when Epic and Id suggested to Activision use their 3D engine instead of rolling their own-- which was a new idea. (As an aside -- seeing the pre-release editor for Unreal was eye opening at that time)

The business (or hobby) has gone from depending on people having the technical skill to make a game being the most important thing to having the marketing skill to find an audience as the most important thing.

Kinda just wanted to say the same thing.

When I taught in London I gave the physics and sound part of a "game design" course. The undergrads built their own game engine over three years and used it to deliver their final project. They started out with pong and ended up with a full 3D framework with lighting, sound, physics, collisions and object managers. They had to sit through lectures on space partitions, quaternions, graph theory, ray tracing, audio DSP... those kids really went through the mill.

I guess a lot of those students went on to do great things, but around 2015 I noticed a shift where;

1) We couldn't get the recruits with the right maths backgrounds any more. The kids just wanted to do more aesthetic design stuff.

2) Game companies seemed less interested in hiring them. I put that down to a slump in the market, but looking back; the age of the programmer-developer was over. Games engines became like commercial operating systems. You either used Unreal or Unity and the closest to programming you got was with middleware (blueprint and the like) which was mostly template dataflow.

As a publisher you would prefer to work with people who don't make their own engines. As a developer you are kind of wary of the guy who wants to write his own renderer. That person is going to be bored scripting.

Plus, twenty five years ago a game developer could afford to hire the person with the chops to right a renderer. We used to be able to get people from Cal Tech rolling off aerospace companies after the cold war. Now people with those skills are way too expensive to hire.

> As a developer you are kind of wary of the guy who wants to write his own renderer.

Yeah that has resonance here I'm sure. Unless you're in the business of developing game engines, but competition made that a very small space. Oh well, they learned a lot. It'll come in useful eventually.

There is nothing wrong with making your own engine in fact it can be a good choice if you're able to stay focused on your goal.

A lot of people who want to make games get caught up on the engine aspect and never end up making a game because they look at what other engines have and assume that they need those features.

Instead of asking what features their game needs.

So if you're making a game and want to use a custom engine then make sure you only build what your need and not what you want.

I made this mistake and spent years on and off working on a game , i had no plan or goal other than "I want to make a game"

In the end i got something that looked kinda pretty if you squint, not a game .

That's what the video states

another advice is Know the consequences of your licenses if you use someone else's engine, and whether they can change terms on you. See: the unity controversy

Make your own game engine until you need to use something else.

Seriously, some game engines are overkill. Some are not enough. And sometimes, you want the engine to be the difference.

Plenty of games have their own engine.

This has the risk of you spending time bikeshedding about the engine and forgetting to actually make the game.

It's a lot easier to grab a ready made engine like pygame, godot or even Unity and make the damn game first.

Then when you know your concept works you can port it to your custom bespoke engine if it's still a viable idea.

You know what is worse than making your own engine? Spending ungodly amounts of debugging some redicilously stupid issue because you didn't check a "bloo fobar" checkbox under floo - bar - baz setting menu (that exists only in your awesome engine version 19.10 but NOT in all previous versions) and you didnt have a slightest fking clue what to do and how to solve it if only not for a random single forum post from 2011 explaining it. meh. I'd rather debug my own bugs than this shit.

Agreed but IME this has more to do with the mixture of GUI and scripting workflows that turn everything into undiscoverable spaghetti. I don't nearly come into this problem with entirely-code-based frameworks even with little documentation because you can trivially trace any call stack

Which powerful engine acts as a library rather that gui spaghetti?

Reply on news.ycombinator.com