Live data from Hacker News

Create your own Game Engine but don't use it

zeroequalsfalse.press

81–90 of 113 posts

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

#81

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…

Would you mind sharing your text editor?

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

#82

There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…

First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.

However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.

It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.

It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.

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

#83
post #73

There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…

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 language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.

This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.

If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.

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

#84

Earlier quoted context omitted.

This is why i prefer frameworks like LÖVE 2d. it's so simple that I can keep everything I need in my head. I like just staying in the text editor.

I really wanted to like love 2d, but I found the community very unfriendly, and there were some fairly simple old bugs that have been around a long time. Also, I was looking for something to teach children, and they seem to like "hilarious" library names like anal. (This is not one of the problems I asked about, I knew better than to ask someone to rename something).

They recently (about a year ago at least) changed nearly all of the library names.

They also had the friendliest community I had ever been in on IRC, besides maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear things had changed on that front.

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

#85

Earlier quoted context omitted.

Huge Carmack fan here but I feel the need to defend the latest hi-octane Doom incarnation from 2016 - IMHO great controls, fast old-school gameplay, superbe graphics.

I'd agree. The single-player for the new Doom was excellent, but not groundbreaking. The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.

If tacking on a few Overwatch bits means I'll be able to find matches, let it be. Quake Live has been pretty dead for a while now.

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

#86

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. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line o…

Piping together the other programs is certainly practical and efficient...but spending a whole ton of time writing complex code is fun. I tend to take the practical route at work, an the impractical route when I'm writing something for fun.

In my perfect world, I'd be writing something for which there are no existing libraries to lean on.

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

#87

Earlier quoted context omitted.

I really wanted to like love 2d, but I found the community very unfriendly, and there were some fairly simple old bugs that have been around a long time. Also, I was looking for something to teach children, and they seem to like "hilarious" library names like anal. (This is not one of the problems I asked about, I knew better than to ask someone to rename something).

They recently (about a year ago at least) changed nearly all of the library names. They also had the friendliest community I had ever been in on IRC, besides maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear things had changed on that front.

I'll have a look, because I am still on the lookout for something after scratch -- I currently use pygame but I love the idea of love2d.

Maybe I just caught the IRC channel on a really bad day, or asked some particularly offensive question, without knowing what I was doing.

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

#88

Earlier quoted context omitted.

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…

First of all, I'm talking about game engines , not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting. However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure. It's certainly possible to work around GC pauses, but that effectively means you are manually…

Some of the work done to work around GC feels similar to the work you'd do in C/C++ to work around memory fragmentation issues. Also, depending on the language/runtime, you might be able to influence the GC algorithm, or at least the frequency with which it runs. If you can e.g. run a GC every second for not longer than ~1 frame, then pauses won't be noticeable.

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

#89

Earlier quoted context omitted.

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…

First of all, I'm talking about game engines , not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting. However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure. It's certainly possible to work around GC pauses, but that effectively means you are manually…

Even if there was entirely non-stop GC (e.g. through reference counting) it's still wouldn't be a good choice for games since a game is, essentially, just a neatly arranged data structure in memory. Compared to the amount of memory a game reads/writes every frame all other I/O channels are just noise. You actually want to manage your memory instead of trying to figure out how to force a foreign memory system to do what is best.

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

#90
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…

On a past life I used to be an IGDA member, attended GDCE a couple of times, and knew personally developers working in a few European game studios, until deciding boring IT work was a better way to make a living and enjoying life.
Post reply on HN