Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A 2D game engine in under 1000 lines of C

github.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Show HN: A 2D game engine in under 1000 lines of C

#11

Post by TeMPOraL »

jsd1982 wrote: post #4

Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…

WRT, the header files, given the size and contents of basque.c, I'd say it's just a placeholder/example file, and that the engine is by design a header-only library. Which is fine, IMO. Though the headers don't feature guards against multiple includes, which is surprising.

Re: Show HN: A 2D game engine in under 1000 lines of C

#12

Post by ryanpcmcquen »

TeMPOraL wrote: post #11
jsd1982 wrote: post #4

Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…

WRT, the header files, given the size and contents of basque.c, I'd say it's just a placeholder/example file, and that the engine is by design a header-only library. Which is fine, IMO. Though the headers don't feature guards against multiple includes, which is surprising.

I don't want to add #pragma once until I am ready to ship the game. This way I will know right away if I do any redundant includes.

Re: Show HN: A 2D game engine in under 1000 lines of C

#13

Post by ryanpcmcquen »

jsd1982 wrote: post #4

Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…

Thank you for the feedback and gist, I will take it into consideration.

We use the 'happy path' style at work. It is OK. I find it has its own set of disadvantages as well. I am also not a fan of negative/negating conditions.

Whenever possible, I try to write the code the way I would explain it in plain language. This may be antithetical to the majority of modern programming, but I am OK with that.

Re: Show HN: A 2D game engine in under 1000 lines of C

#14

Post by ryanpcmcquen »

caymanjim wrote: post #2

What's with the majority of the code being in header files?

I know that using .c and .h files is the traditional way of doing it in C, and I started the engine this way, but to be honest, is there any gain to it in this scenario?

The headers are library code, and having more files just means more maintenance and build complexity. Is there another advantage I am not aware of?

Re: Show HN: A 2D game engine in under 1000 lines of C

#15

Post by jdmoreira »

ryanpcmcquen wrote: post #14
caymanjim wrote: post #2

What's with the majority of the code being in header files?

I know that using .c and .h files is the traditional way of doing it in C, and I started the engine this way, but to be honest, is there any gain to it in this scenario? The headers are library code, and having more files just means more maintenance and build complexity. Is there another advantage I am not aware of?

You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only

Re: Show HN: A 2D game engine in under 1000 lines of C

#16

Post by babuskov »

caymanjim wrote: post #2

What's with the majority of the code being in header files?

Using header files is great when starting new projects. When I wrote my first game engine, I tried to keep everything in .h files. There are two benefits:

A minor one, but still saves some time: You don't have to think about build system. Just compile a single .c file on the command line. You can quickly add and remove .h files while prototyping, without having to add/remove files to the project.

A major one: is that you cannot create cyclic dependencies. This helps to get your call hierarchy right. When using header files only, the only way to get cyclic dependency is to use a forward declaration and every time you feel like you need to do that, a big red flag is raised in your mind. And then you start to think how to do it properly. This is even more important in C++ where you have to think about responsibilities of every class. It prevents you from creating too coupled code.

When the project grows and compilation times get long, you should split all of those into separate compilation units, so that you can use multi-threaded builds (via ninja, or make -j).

Re: Show HN: A 2D game engine in under 1000 lines of C

#17

Post by meheleventyone »

blondin wrote: post #5
jsd1982 wrote: post #4

Looking at your `init` function, I would refactor it to not be so nested with if statements. Try logically inverting the if checks and returning early up near the top of the method and remove the else branches. Keep repeating this kind of refactoring on all your if statements. Eventually, you'll find that the "happy path" ends up at the bottom of the method and can return a success status without being so far indente…

nested ifs work here too. i personally don't think cognitive overload is an issue because you are not composing all the conditions at once. in fact, each block should only care about one condition. but you make a good point. tbh, i have seen nested ifs used in video game programming a lot. and i came to the conclusion that it has to do with the else clause that the return early method doesn't provide. the else clause…

The early return is the else block.

I also wanted to comment on needing it because games aren’t supposed to fail. The way you actually do that is not to try to recover from errors but to surface them quickly and fix them at the point of failure. Ideally before shipping. Recovery is usually very difficult because games are a collection of very dependent state and if you don’t recover correctly letting the game continue after an error is very likely to result in all sorts of other bizarre issues happening. This can also be very subtle where the accumulation of errors leads to a sudden obvious issue and finding the root cause is very difficult. Whereas failing early and loudly makes things much easier.

Re: Show HN: A 2D game engine in under 1000 lines of C

#19

Post by pjmlp »

babuskov wrote: post #16
caymanjim wrote: post #2

What's with the majority of the code being in header files?

Using header files is great when starting new projects. When I wrote my first game engine, I tried to keep everything in .h files. There are two benefits: A minor one, but still saves some time: You don't have to think about build system. Just compile a single .c file on the command line. You can quickly add and remove .h files while prototyping, without having to add/remove files to the project. A major one: is that…

File->New Project isn't that hard.

Re: Show HN: A 2D game engine in under 1000 lines of C

#20

Post by w0utert »

caymanjim wrote: post #2

What's with the majority of the code being in header files?

It's not uncommon in game development to do 'unity builds', by basically including all code to get a single compilation unit. It can reduce build times and the compiler has more options for optimizations (inlining, mostly). This doesn't require putting everything in header files, just including the .c files gets you the same result. But if you're doing unity builds the distinction between header files and source files is basically reduced to the file extension anyway...
Post reply on HN