Hold on, there... It's a false analogy that engine programmers are to Unity developers as horseback riders are to car drivers- seriously?
A more apt analogy is that engine programmers are to Unity developers as car mechanics EDIT: (actually more car engineers than mechanics) are to car drivers.
A more apt analogy is that engine programmers are to Unity developers as car mechanics EDIT: (actually more car engineers than mechanics) are to car drivers.
Edited by Ryan Fleury
on
@lost: I have nothing against Unity. If somebody wants to use it, that's perfectly fine way to create games. I just used name "Unity" instead of "whatever-ready-game-engine". HH is about what takes on the lowest level to create game engines. Somebody needs to know how manufacture those cars. If you don't like that, then HH is not for you. And that is also perfectly fine. It seems you want HH simply to be something that it is not. I don't understand why you want HH to be something else. Casey teaches what he knows and can do best. And he does this in the best way - he not only shows how to do things, but shows why they are like that, what are alternative and explains what happens inside "black-box" APIs. Why this is an issue for you? What is alternative resource to learn about this? Good example is what you mentioned earlier in topic - "use new and delete instead malloc and free" - this is the reason why HH exists. Instead of only saying "do this", HH explains "why" to do things it does.
Edited by Mārtiņš Možeiko
on
You guys take offense really easily, even when I pepper my commentary with praise.
I think a better metaphor is not a car mechanic, but rather an automotive engineer at GM. Wouldn't that be closer to what you are talking about, since mechanics use off the shelf parts from the dealership, but you guys are trying to design those off the shelf parts?
Brian Fargo said it best when he said "We make games, not technology. We're not a technology company, we're a game company."
Related: http://www.rpgcodex.net/forums/in...s/wasteland-2-to-use-unity.72117/
It's easy to get lost in the corridors of "low level technology development" when making a game quickly and effectively involves more creative work at the middle and high levels.
Anyway I doubt there's anything lower level than pod-wrapping-classes *my own work ZeroTypes*, except maybe bit shaking and assembler. But why would anyone want to reimplement floating point on the course to creating a fun shooter?
I think a better metaphor is not a car mechanic, but rather an automotive engineer at GM. Wouldn't that be closer to what you are talking about, since mechanics use off the shelf parts from the dealership, but you guys are trying to design those off the shelf parts?
Brian Fargo said it best when he said "We make games, not technology. We're not a technology company, we're a game company."
Related: http://www.rpgcodex.net/forums/in...s/wasteland-2-to-use-unity.72117/
It's easy to get lost in the corridors of "low level technology development" when making a game quickly and effectively involves more creative work at the middle and high levels.
Anyway I doubt there's anything lower level than pod-wrapping-classes *my own work ZeroTypes*, except maybe bit shaking and assembler. But why would anyone want to reimplement floating point on the course to creating a fun shooter?
Edited by Lost Astronaut Studios
on
Because you are not making a coherent argument.
There's already a lengthy thread where the direction of HMH has been quite thoroughly discussed.
https://hero.handmade.network/for...ssion/t/2783-where_is_this_headed
While I do agree that most things Casey does on stream are not really necessary (in context of making indie games). Hot reloading is not one of those unnecessary things.
Code hot reloading improves iteration times and workflow significantly.
It is one of the most important "engine" features, closely followed by a) asset hot-swapping (backed by filesystem events) and b) data-structure / game entity hot swapping.
There's already a lengthy thread where the direction of HMH has been quite thoroughly discussed.
https://hero.handmade.network/for...ssion/t/2783-where_is_this_headed
While I do agree that most things Casey does on stream are not really necessary (in context of making indie games). Hot reloading is not one of those unnecessary things.
Code hot reloading improves iteration times and workflow significantly.
It is one of the most important "engine" features, closely followed by a) asset hot-swapping (backed by filesystem events) and b) data-structure / game entity hot swapping.
Edited by pragmatic_hero
on
I gather you like hot reload. Great. Use it. No one is stopping you from using it. It's a feature of JUCE. If you used JUCE you wouldn't have to implement it yourself, and it would build on 3 platforms.
I prefer to write while my compiler compiles. You prefer to "hot swap" code. I like to write a concise plan in advance, because that's what I'm used to. Also, I don't feel like reaching down to the OS level for everything, nor mucking with memory at that level. I spend most of my time when not spent doing other things devising editors which allow me to change effects on the fly anyway, and increase the features for third-party modding.
"Because you are not making a coherent argument."
I don't think that's true and I wasn't here to argue. My assertion was simply that spending 200 videos writing a 2D engine and then throwing it away indicates your project lacked a cohesive plan from the start. Also, I kind of wish I followed Brian Fargo's advice before I started down the path of writing my own engine. That way I'd have spent more time developing a game and not an engine.
Anyway, moot point.
I prefer to write while my compiler compiles. You prefer to "hot swap" code. I like to write a concise plan in advance, because that's what I'm used to. Also, I don't feel like reaching down to the OS level for everything, nor mucking with memory at that level. I spend most of my time when not spent doing other things devising editors which allow me to change effects on the fly anyway, and increase the features for third-party modding.
"Because you are not making a coherent argument."
I don't think that's true and I wasn't here to argue. My assertion was simply that spending 200 videos writing a 2D engine and then throwing it away indicates your project lacked a cohesive plan from the start. Also, I kind of wish I followed Brian Fargo's advice before I started down the path of writing my own engine. That way I'd have spent more time developing a game and not an engine.
Anyway, moot point.
Edited by Lost Astronaut Studios
on
You're right, that's even better- an engineer (now that I think of it more clearly, a car mechanic wouldn't really make as much sense). My point was that an individual riding horseback is the worst possible analogy for the situation, which you've demonstrated your knowledge of.
I think we should all take care to not provoke a toxic debate. We should certainly have discussions about programming styles so that we can all converge to the best possible engineering methodology, but that does not imply we should become hostile or bitter towards one another. We should also remember that programming skill is not some sort of scalar value; there are several approaches to the same problem, many of which may be valid.
The point of Handmade Hero was to be an educational project to encourage programmers to learn more about lower-level concepts, understand the full stack behind game engines, and promote higher quality software engineering. It has already accomplished that goal, as made clear by the existence of Handmade Network. This community already has several software projects that are made in a way not that different from Handmade Hero, are cross-platform, and are high quality.
@lost, I think you have to understand the fact that you're criticizing some aspects that are literally the foundation of Handmade Network; not necessarily hot-reloading, but the nature of programming at a low level and fundamentally understanding what the computer is doing (and how that is helpful to software development and therefore quality). The spirit of Handmade Network is not to reject the higher levels of development, but rather to understand why particular higher level design decisions are made. In my opinion, it is built around the idea that a programmer is empowered by their ability to construct higher level concepts that are helpful to them (as opposed to relying on higher level constructs that are forced upon the programmer, like in several higher level languages). That's why a lot of developers here use C or C++, because those are two languages that allow a higher degree of freedom with regards to constructing useful abstractions for a particular problem.
I think we should all take care to not provoke a toxic debate. We should certainly have discussions about programming styles so that we can all converge to the best possible engineering methodology, but that does not imply we should become hostile or bitter towards one another. We should also remember that programming skill is not some sort of scalar value; there are several approaches to the same problem, many of which may be valid.
The point of Handmade Hero was to be an educational project to encourage programmers to learn more about lower-level concepts, understand the full stack behind game engines, and promote higher quality software engineering. It has already accomplished that goal, as made clear by the existence of Handmade Network. This community already has several software projects that are made in a way not that different from Handmade Hero, are cross-platform, and are high quality.
@lost, I think you have to understand the fact that you're criticizing some aspects that are literally the foundation of Handmade Network; not necessarily hot-reloading, but the nature of programming at a low level and fundamentally understanding what the computer is doing (and how that is helpful to software development and therefore quality). The spirit of Handmade Network is not to reject the higher levels of development, but rather to understand why particular higher level design decisions are made. In my opinion, it is built around the idea that a programmer is empowered by their ability to construct higher level concepts that are helpful to them (as opposed to relying on higher level constructs that are forced upon the programmer, like in several higher level languages). That's why a lot of developers here use C or C++, because those are two languages that allow a higher degree of freedom with regards to constructing useful abstractions for a particular problem.
lost
I don't think that's true and I wasn't here to argue.
You can't have it both ways.
You can't make unsubstantiated statements like this:
lost
as for this relationship to Hot-Reload .. well, I'm not sure why you would implement this unless you expected your game engine to be very volatile and poorly implemented
And then conveniently backpedal from it, and then turn the whole thing into a "preference".
Because "Iteration time" is NOT a preference. "Iteration Time" is a measurable quantity.
For a small-medium sized game - code hot-reloading reduces iteration time to 100ms-2s (depending on the compiler used and the amount of code).
Versus 5-15secs (or an order of magnitude more easily) - OpenGL initalization/context creation = couple hundred ms, loading assets, compiling shaders, if you use OpenAL extra 200-300ms, loading levels, restoring the game to a state where the change can be observed. It all adds up quite fast.
Saying "well, i can take a walk in the park", does not reduce iteration time and is not a valid argument.
Considering how easy it is to add HMH style code swapping and the amount of flexibility it adds, the alternatives of scripting languages (or) all sort of tweak-able value-gizmos (or) some elaborate data-driven systems, are simply not proper substitutes by themselves - and all have significant costs and limitations.
Plus, code hot-swapping in combination with even a simple IMGUI system allows you to write and add editing gizmos and editor parts while the game is running.
Moreover it is perfectly fine if the code hotswapping works only on the dev-machine.
Just to nail the point home - pretty much all "modern" engines have some form of Code/Asset Hot Reload (incl. Unity, Unreal, etc)
Well, guess what, game-developers prefer to have iteration times as short as possible - ideally changes reflected instantly.
lost
My assertion was simply that spending 200 videos writing a 2D engine and then throwing it away indicates your project lacked a cohesive plan from the start. Also, I kind of wish I followed Brian Fargo's advice before I started down the path of writing my own engine. That way I'd have spent more time developing a game and not an engine.
This is clearly off-topic. There is a separate thread to debate this.
Edited by pragmatic_hero
on
pragmatic_herolost
I don't think that's true and I wasn't here to argue.
You can't have it both ways.
You can't make unsubstantiated statements like this:
lost
as for this relationship to Hot-Reload .. well, I'm not sure why you would implement this unless you expected your game engine to be very volatile and poorly implemented
Oh I guess I thought it was something else. http://www.mudbytes.net/forum/topic/1368/ You're talking edit-and-resume or as microsoft calls it "edit and continue" https://msdn.microsoft.com/en-us/....aspx?f=255&MSPPError=-2147217396 .. I thought it had something to do with "allowing an engine to crash and reboot" within an application, which has been the solution of several industry game engines that "got too big" and too gnarled
I retract that statement, sure. I don't think I can use what you are calling 'hot reload' in my project.
Edited by Lost Astronaut Studios
on
"@lost, I think you have to understand the fact that you're criticizing some aspects that are literally the foundation of Handmade Network; not necessarily hot-reloading, but the nature of programming at a low level and fundamentally understanding what the computer is doing (and how that is helpful to software development and therefore quality). The spirit of Handmade Network is not to reject the higher levels of development, but rather to understand why particular higher level design decisions are made. In my opinion, it is built around the idea that a programmer is empowered by their ability to construct higher level concepts that are helpful to them (as opposed to relying on higher level constructs that are forced upon the programmer, like in several higher level languages)."
I just thought it was a place where makers made things. This sounds 'deeply philosophical'
"That's why a lot of developers here use C or C++, because those are two languages that allow a higher degree of freedom with regards to constructing useful abstractions for a particular problem."
I chose C++ because it is fast and is right for the platform I chose at the time (desktop PCs). I did not choose it because it offers a higher degree of freedom. eC (a project I worked on directly prior to diving into C++) at ecere.org offered me far more "freedoms" as far as the actual Tao of Ecere and the way you write code is. It's way more empowering, too, excepting that C++ is supported by a billion dollar company and Ecere's compiler and IDE doesn't have the kind of budget a free IDE like Visual Studio offers.
lost
I just thought it was a place where makers made things. This sounds 'deeply philosophical'
Handmade Network has always been philosophical in nature.
It is about making things, but it's about making things with care for what is happening in the pursuit of producing quality software that respects the user and the computer.
Yes I admit it was a bit of a hijack. Thanks Jack. Yeah doing a hot shader reload is useful and easy. "Hot reload" (if that is really the correct term, its kind of borrowed from the Web) just simply isn't available to my project, since I haven't spent the time removing core .lib dependencies but also probably because my set up seems to be fairly unique (also I'm only in 32-bit mode ... I'm stuck there due to the legacy of my C++ project and its DLL dependencies are too numerous, so some are not available in 64-bit).
Hey a while back someone said " I recommend explicitly handling errors (in my opinion, this is the only type of error handling that should occur). Exceptions are not necessary for that."
For "new" and "delete" operators you are going to want to use try ... catch .. generally you'd use try catch for certain types of error handling, regardless of your personal preference -- it's depending on the requirements of the code you are using. Some libraries require it, and in some cases its safer code -- like lower level stuff, networking and whatnot it may be useful or required. It's not always necessary to use try ... catch.
Hey a while back someone said " I recommend explicitly handling errors (in my opinion, this is the only type of error handling that should occur). Exceptions are not necessary for that."
For "new" and "delete" operators you are going to want to use try ... catch .. generally you'd use try catch for certain types of error handling, regardless of your personal preference -- it's depending on the requirements of the code you are using. Some libraries require it, and in some cases its safer code -- like lower level stuff, networking and whatnot it may be useful or required. It's not always necessary to use try ... catch.
Edited by Lost Astronaut Studios
on