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

Create your own Game Engine but don't use it

zeroequalsfalse.press

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Create your own Game Engine but don't use it

#101

Post by krapp »

nbm wrote: post #56
fellellor wrote: post #39

Earlier quoted context omitted.

Handmade Hero is over 380, hour or two long videos last i saw. How far are you into it? Regardless, it's an amazing effort.

I've watched pretty much every episode, mostly live. It is pretty amazing. It also pretty much single-handedly reinvigorated my love of programming. But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build. https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch. Of…

>But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build.

That's been one of my biggest problems with Handmade Hero - Casey isn't teaching people how to write C/C++ and build a game engine, he's teaching them how he builds one specific game and mixing his personal habits (and idiosyncratic prejudices) along with some very useful programming knowledge.

And he also shut down comments on the Youtube feed at some point, which I find very unfortunate. The commenters helped me gauge the BS factor for any particular episode before jumping in.

Re: Create your own Game Engine but don't use it

#102

Post by krapp »

This is apparently what I've been doing for about two years.

Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever."

I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just hated every thing about the code.

And this is why I am an amateur programmer and a professional box-pusher.

Re: Create your own Game Engine but don't use it

#103

Post by anth1988 »

thomascgalvin wrote: post #9

This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked. The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be l…

> Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom

or it relegates you to never doing an interesting thing.

Re: Create your own Game Engine but don't use it

#104

Post by tisdy »

krapp wrote: post #102

This is apparently what I've been doing for about two years. Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever." I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just…

I'm interested in pushing boxes. It sounds relaxing. Well, relatively. Have you heard of webpack?

Re: Create your own Game Engine but don't use it

#105

Post by pjmlp »

karmadog wrote: post #100
pjmlp wrote: post #99

Earlier quoted context omitted.

> So what? Those words probably had a good argument behind them, at the time. > In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off. Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, have enough work placed into them, that eventually they will become competitive against C. People believed they cou…

If makes certain assumptions and guarantees on behavior, then no, belief is not enough. It has to be plausible. GC alone really is a big issue and all the research (of which there is a lot) has not solved fundamental issues. There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.

The fundamental issues is that science only advances one memorial at a time, as there is no amount of technical proofs that will change the mind of luddites.

Re: Create your own Game Engine but don't use it

#106

Post by krapp »

tisdy wrote: post #104
krapp wrote: post #102

This is apparently what I've been doing for about two years. Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever." I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just…

I'm interested in pushing boxes. It sounds relaxing. Well, relatively. Have you heard of webpack?

I have heard of it, but I've never used it. I'm far, far behind the curve when it comes to anything involving web development. It's on my list of things to look at.

Re: Create your own Game Engine but don't use it

#107

Post by RugnirViking »

krapp wrote: post #101
nbm wrote: post #56

Earlier quoted context omitted.

I've watched pretty much every episode, mostly live. It is pretty amazing. It also pretty much single-handedly reinvigorated my love of programming. But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build. https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch. Of…

>But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build. That's been one of my biggest problems with Handmade Hero - Casey isn't teaching people how to write C/C++ and build a game engine, he's teaching them how he builds one specific game and mixing his personal habits (and idiosyncratic prejudices) along…

'he's teaching them how he builds one specific game '

While I would agree that there may perhaps exist a better alternative, most of us have learned a difficult concept or two by finding a working example. This is that, but taken up to 11. Assuming you actually follow on and try to make -small- variations to ensure you understand whats going on, you will probably be in a great position

Re: Create your own Game Engine but don't use it

#108

Post by brianwawok »

Bartweiss wrote: post #76
brianwawok wrote: post #50

Earlier quoted context omitted.

Except for some of us, it isn't actually that fun to spend 5 minutes gluing together 6 libraries with no documentation, and 4 hours figuring out an undocumented bug deep in the source code. We would rather write someone from scratch :) Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.

> 4 hours figuring out an undocumented bug deep in the source code For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo. Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the…

Everything is broken at some level. Your own code will have bugs just like the lib you import will.

Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.

Re: Create your own Game Engine but don't use it

#109

Post by Bartweiss »

brianwawok wrote: post #108
Bartweiss wrote: post #76

Earlier quoted context omitted.

> 4 hours figuring out an undocumented bug deep in the source code For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo. Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the…

Everything is broken at some level. Your own code will have bugs just like the lib you import will. Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.

Yep, I certainly don't mean to imply my code is right. But it's usually shorter, and it's mine. So when I find the bug, I can make the sane fix on the schedule I need.

For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.

Re: Create your own Game Engine but don't use it

#110

Post by yellowapple »

xemdetia wrote: post #83
pjmlp wrote: post #73

Earlier quoted context omitted.

1. Refusing to just use Assembly. Was the reply we got in the old days, when one used C, Pascal, Basic, Amos. Thankfully many ignored that and moved the state of art to such languages. A few years later the reply would be, 1. Refused to use C When devs tried to use C++ or Delphi. State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.

I don't really feel like this is a fair statement if you have done any game engine related development. Even 'writing from scratch' is still gluing together a whole soup of libraries and many of those libraries are C API only. Fonts? Use freetype. PNG's? use libpng. COLLADA? Audio? Audio files? Input? OpenGL/DX? As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the…

A growing number of languages are ABI-compatible with C. A small but significant subset of those languages is ABI-compatible with C++. Quite a few languages (Perl 6, Julia, Tcl w/ critcl, pretty much everything that uses libffi AFAICT) are able to do this without having to write full-blown wrappers for a whole C/C++ library (though you still need to wrap specific functions in most cases).
Post reply on HN