Use Unity or Unreal? Surely you must be joking Casey? That's a good one! LOL After watching your compression oriented programming technique and exploratory programming method, I could never return to general purpose engines, nor object oriented programming. They feel like creative jail and torture by comparison.
Having said that, there are many good teachers for game programming. Just get on Youtube and take your pick.
Having said that, there are many good teachers for game programming. Just get on Youtube and take your pick.
Edited by Mór
on
Hey everyone, I actually registered just now because I wanted to chime in from maybe a different perspective.
So I can definitely understand that some are concerned because the series has taken a different turn than was maybe originally intended, and I myself have been concerned that the series would crawl to a halt before, because I think some of us are still secretly waiting to confirm that yeah, you actually can still make a complete engine/game from scratch in this day and age. That was my perspective anyway.
I have been following Handmade Hero almost from the start, I think I started watching a couple weeks after the project launched, and I've followed the first 130 or so episodes as they went live on Youtube and then watched later ones from time to time until I decided to code along and write my XLib Linux port and started from Day 1 again. And I restarted from Day 1 once more for my second try at the port which is going quite well now (on Day 122, yay). So in this time I found out I am exactly the type of person who gets the most out of the series, I am far more interested in the technical aspects and want to know more and more about the maybe niche stops and digressions the episodes have gone lately (I skim the newer episodes to keep me excited for what I still have to cover). I've sunk at least 250h+ on Handmade Hero + all the hours researching other resources on graphics programming and math it inspired me to go through, so it has been a full-on hit for my tastes.
I am just one guy but to me it seems Casey knows what he is doing and what the best thing he can offer are, for instance I cannot wait to get to the lighting episodes which is a huge interest for me. On the other hand I enjoy the 'slower' pace because my actual programming job which I also enjoy is not at all related, so I can maybe see that some people would be more eager to get to see a full 'first-pass' of a complete game rather than some parts of an engine they might not use in a lot of games. But again, I never got the impression that Handmade Hero was ever meant to be that sort of a thing.
So I can definitely understand that some are concerned because the series has taken a different turn than was maybe originally intended, and I myself have been concerned that the series would crawl to a halt before, because I think some of us are still secretly waiting to confirm that yeah, you actually can still make a complete engine/game from scratch in this day and age. That was my perspective anyway.
I have been following Handmade Hero almost from the start, I think I started watching a couple weeks after the project launched, and I've followed the first 130 or so episodes as they went live on Youtube and then watched later ones from time to time until I decided to code along and write my XLib Linux port and started from Day 1 again. And I restarted from Day 1 once more for my second try at the port which is going quite well now (on Day 122, yay). So in this time I found out I am exactly the type of person who gets the most out of the series, I am far more interested in the technical aspects and want to know more and more about the maybe niche stops and digressions the episodes have gone lately (I skim the newer episodes to keep me excited for what I still have to cover). I've sunk at least 250h+ on Handmade Hero + all the hours researching other resources on graphics programming and math it inspired me to go through, so it has been a full-on hit for my tastes.
I am just one guy but to me it seems Casey knows what he is doing and what the best thing he can offer are, for instance I cannot wait to get to the lighting episodes which is a huge interest for me. On the other hand I enjoy the 'slower' pace because my actual programming job which I also enjoy is not at all related, so I can maybe see that some people would be more eager to get to see a full 'first-pass' of a complete game rather than some parts of an engine they might not use in a lot of games. But again, I never got the impression that Handmade Hero was ever meant to be that sort of a thing.
What Casey is saying kind-of reinforces the widespread misconception that its either UnityTown, UnrealTown or GameMakerTown or you have to make your own *Engine* with the capital letter E implying a major effort and hairy complexity, requiring technical acumen of Carmack and alike.
Where you have to learn and implement "all these things".
While actually you have to do almost none of them.
Which is a bit of a shame really, as otherwise HMH has been very effective at cutting through bullshit.
Where you have to learn and implement "all these things".
While actually you have to do almost none of them.
Which is a bit of a shame really, as otherwise HMH has been very effective at cutting through bullshit.
Engines don't even make much sense outside of triple-A context anymore.
Those times be over lads.
The engines are dead. They are all *dead*.
Who killed the engines you might ask? The GPUs killed the engines.
If you can load and render complete levels of half-life and have FPS in thousands,
without any kind of occlusion culling or spatial partitioning smartassery.
There's not much of an engine to be had, is there?
With this amount of raw power, everything becomes fairly straight forward.
When people talk about Unity it's usually "Unity-like workflow" rather than the "Unity the game engine".
It's the workflow which ultimately sells it. (not having to deal with C++ bullshit also helps)
Those times be over lads.
The engines are dead. They are all *dead*.
Who killed the engines you might ask? The GPUs killed the engines.
If you can load and render complete levels of half-life and have FPS in thousands,
without any kind of occlusion culling or spatial partitioning smartassery.
There's not much of an engine to be had, is there?
With this amount of raw power, everything becomes fairly straight forward.
When people talk about Unity it's usually "Unity-like workflow" rather than the "Unity the game engine".
It's the workflow which ultimately sells it. (not having to deal with C++ bullshit also helps)
I get why the workflow of 3D engines is helpful, where you can drag and drop things visually, but when it comes to 2D those editor engines just get in the way.
I've also come to the opinion that 3D engines are a big waste of time, because the little indies can't afford competitive assets, and even mid-tier devs with millions more to spend, regularly complain that AAA companies run them out of business using superior production values. 3D is good for dreams, but little else.
I've also come to the opinion that 3D engines are a big waste of time, because the little indies can't afford competitive assets, and even mid-tier devs with millions more to spend, regularly complain that AAA companies run them out of business using superior production values. 3D is good for dreams, but little else.
Edited by Mór
on
pragmatic_hero
Engines don't even make much sense outside of triple-A context anymore.
Those times be over lads.
The engines are dead. They are all *dead*.
Who killed the engines you might ask? The GPUs killed the engines.
If you can load and render complete levels of half-life and have FPS in thousands,
without any kind of occlusion culling or spatial partitioning smartassery.
There's not much of an engine to be had, is there?
With this amount of raw power, everything becomes fairly straight forward.
When people talk about Unity it's usually "Unity-like workflow" rather than the "Unity the game engine".
It's the workflow which ultimately sells it. (not having to deal with C++ bullshit also helps)
All a gpu does is render triangles
However a game engine needs to do a lot more. Collision checks for example are O(n^2) unless you have some kind of broad-phase spatial culling.
If you have to NxN collide more than a couple dozen objects, you will need a broadphase. Doesn't have to be complicated.
If you're making a game about controlling armies of 100k soldiers or more,
it's core feature of the game and you have to do the tech make it happen.
The tech there is game specific and borne out of necessity instead of being apriori decided arbitrary "generic engine feature X".
And therin lies the main criticism of the direction HMH unfortunately has taken:
For a process of making a game - without using an engine - from A to Z - the prioritization is off-kilter.
Every tech feature has to be either an absolute necessity or a force-multiplier (workflow).
Teaching that mindset I believe is an order of magnitude more important than some tech minutiae.
And I like rotating teapots and AVX2 instructions as much as the other guy.
If you're making a game about controlling armies of 100k soldiers or more,
it's core feature of the game and you have to do the tech make it happen.
The tech there is game specific and borne out of necessity instead of being apriori decided arbitrary "generic engine feature X".
And therin lies the main criticism of the direction HMH unfortunately has taken:
For a process of making a game - without using an engine - from A to Z - the prioritization is off-kilter.
Every tech feature has to be either an absolute necessity or a force-multiplier (workflow).
Teaching that mindset I believe is an order of magnitude more important than some tech minutiae.
And I like rotating teapots and AVX2 instructions as much as the other guy.
I've always interpreted the intent of HMH is that the technical stuff is the point of the show, and the game itself is a by-product and only exists to be a platform to showcase whatever feature Casey implements.
The end product of the series will be the game, the codebase and the videos, but creating that game as expediently as possible is obviously not the priority. If it was, I imagine he would be using preexisting engines and libraries to speed up that process.
If all it was trying to be is a stream in which Casey shows step by step how to recreate the original Zelda then sure, HMH probably could have ended 300 episodes ago and almost every engine feature is massive overkill for a game of that scope. However, that isn't going to be much use to someone who wants to make a game that isn't Zelda.
The end product of the series will be the game, the codebase and the videos, but creating that game as expediently as possible is obviously not the priority. If it was, I imagine he would be using preexisting engines and libraries to speed up that process.
If all it was trying to be is a stream in which Casey shows step by step how to recreate the original Zelda then sure, HMH probably could have ended 300 episodes ago and almost every engine feature is massive overkill for a game of that scope. However, that isn't going to be much use to someone who wants to make a game that isn't Zelda.
pragmatic_hero
And therin lies the main criticism of the direction HMH unfortunately has taken:
For a process of making a game - without using an engine - from A to Z - the prioritization is off-kilter.
Every tech feature has to be either an absolute necessity or a force-multiplier (workflow).
Teaching that mindset I believe is an order of magnitude more important than some tech minutiae.
I very strongly disagree with this. That is spoken from the perspective of someone whose primary objective is to make money, not to make technology. Handmade Hero is not about making money. It's about making technology. It's about enjoying programming and showing how to do stuff from scratch, whatever that thing happens to be.
I have no interest in making a show that is about showing people how to be the most efficacious at completing specific game project X in the least amount of time. That's what every other instructional source you ever find will be teaching. We absolutely do not need more of that, in my opinion - we need less of it, because we need more people who explore programming because they love it and enjoy it, and then we get to see what they find at the end of their explorations.
That's the part that's missing these days from programming most of the time. If someone wants to be a cog in a game production machine, they certainly don't need my help - go download an engine and watch tutorial videos, or enroll in Digipen / Full Sail / whatever.
I am only interested in encouraging people to enjoy exploring engine programming for its own sake, full stop.
- Casey
Wanting to do what you enjoy the most, and what you're most qualified to do, absolutely makes sense.
But I would take issue with drawing such a clear cut (and artificial, imo) distinction between game programming and engine programming. It's not as if you're either doing low-level engine work or high-level Unreal blueprints-style design - a lot of stuff falls in between. This notion also reinforces a unidirectional game engine->game code kind of attitude, as opposed to more of a bidirectional feedback loop between the two, which many would argue is valuable (or even necessary) for achieving a certain degree of polish. I'd also venture to guess that a majority of the HMH/potential HMH audience doesn't fit cleanly into either category.
But I would take issue with drawing such a clear cut (and artificial, imo) distinction between game programming and engine programming. It's not as if you're either doing low-level engine work or high-level Unreal blueprints-style design - a lot of stuff falls in between. This notion also reinforces a unidirectional game engine->game code kind of attitude, as opposed to more of a bidirectional feedback loop between the two, which many would argue is valuable (or even necessary) for achieving a certain degree of polish. I'd also venture to guess that a majority of the HMH/potential HMH audience doesn't fit cleanly into either category.
I believe there's value in showing that making a complete game without an engine can be simple and straightforward. And not only it is simple and straightforward, there's *little* work necessary to replicate workflow and the parts which make Unity (and similar engines) appealing.
Showcasing that the tech parts necessary in a non-triple-A game is a very small subset of what is commonly referred to as a "game engine".
I don't think that there are many materials that cover that at all.
Especially interplay of tech code and non-trivial-amounts of non-trivial gamecode.
If anything this minimalistic approach would encourage people to experiment with tech as it shows that it's easy and approachable to get running. And that any tech of any complexity can be easily tailored as necessary when necessary.
There are certain aspects of HMH which make it very appealing for this.
HMH has a non-dogmatic approach, without any preconceived notions of how software development should be done.
That is very refreshing and rare.
But it certainly doesn't display the razor sharp prioritization and pragmatism necessary to ship games outside of game-production-machine where you might have a separate guy doing sweaty ass-cheek physics for the latest iteration of EA NBA game.
They might even have a whole R&D dep toying with tech for making dudes sweat realistically.
Arguably, as it currently stands HMH is training fit for being a specialized cog moreso than anything else really.
Not that there is anything wrong with doing "tech for techs sake". Or toying around with tech. Or being a cog.
It's also clearly not exactly what it says on the tin.
Which is why every once in a while you are bound to get threads like this one.
Has nothing to do with it. Given very finite resources outside of game-production-machine it's a matter of getting stuff done at all.
Showcasing that the tech parts necessary in a non-triple-A game is a very small subset of what is commonly referred to as a "game engine".
I don't think that there are many materials that cover that at all.
Especially interplay of tech code and non-trivial-amounts of non-trivial gamecode.
If anything this minimalistic approach would encourage people to experiment with tech as it shows that it's easy and approachable to get running. And that any tech of any complexity can be easily tailored as necessary when necessary.
There are certain aspects of HMH which make it very appealing for this.
HMH has a non-dogmatic approach, without any preconceived notions of how software development should be done.
That is very refreshing and rare.
But it certainly doesn't display the razor sharp prioritization and pragmatism necessary to ship games outside of game-production-machine where you might have a separate guy doing sweaty ass-cheek physics for the latest iteration of EA NBA game.
They might even have a whole R&D dep toying with tech for making dudes sweat realistically.
Arguably, as it currently stands HMH is training fit for being a specialized cog moreso than anything else really.
Not that there is anything wrong with doing "tech for techs sake". Or toying around with tech. Or being a cog.
It's also clearly not exactly what it says on the tin.
Which is why every once in a while you are bound to get threads like this one.
cmuratori
how to be the most efficacious at completing specific game project X.
Has nothing to do with it. Given very finite resources outside of game-production-machine it's a matter of getting stuff done at all.
Edited by pragmatic_hero
on
NelsonMandella
Wanting to do what you enjoy the most, and what you're most qualified to do, absolutely makes sense.
But I would take issue with drawing such a clear cut (and artificial, imo) distinction between game programming and engine programming. It's not as if you're either doing low-level engine work or high-level Unreal blueprints-style design - a lot of stuff falls in between. This notion also reinforces a unidirectional game engine->game code kind of attitude, as opposed to more of a bidirectional feedback loop between the two, which many would argue is valuable (or even necessary) for achieving a certain degree of polish. I'd also venture to guess that a majority of the HMH/potential HMH audience doesn't fit cleanly into either category.
This is spot on!
godratio
More engine stuff forever I hope you never finish the game.
I'm sure you said this with the best of intentions.
And I got a good laugh out of it.
But you probably shouldn't wish this to anyone. Even an engine programmer.
Considering that Casey until recently was working on a game (not HMH).
pragmatic_hero
But it certainly doesn't display the razor sharp prioritization and pragmatism necessary to ship games
I guess this is the part I'm trying to address but failing to in this thread: I don't care about shipping games. At all. Shipping games is something that you do if you're a game designer, which I am not. I am interested in shipping new technology. Handmade Hero is not about how to ship a game, because that is something that would be better taught by someone who has spent most of their time shipping games! I have only ever shipped game technology, and research-oriented game technology at that, where you are trying to make something new that hasn't been made before. That is the only reason to make things from scratch, in my opinion - if you just want to ship something that is the same as something else, I'm not sure why you wouldn't use that something else as your basis?
Well, that's not entirely true - I guess I can understand somebody saying "I am going to re-make Unity because Unity aggravates me in these ways and I want to make it not aggravating." Maybe that is something worth doing, but it seems like a lot of work to do if you only cared about shipping a game and that game didn't need to do anything new?
Maybe I can summarize by example: if somebody comes away from Handmade Hero knowing how to make the same game they could have made in GameMaker, but without GameMaker, I would be OK with that but not particularly excited. If someone comes away from Handmade Hero knowing how to make a game that has, say, much better lighting than what they got in GameMaker? That would make my day.
Saying "cog in machine" was perhaps too ambiguous here, because what I mean by that is more "cog in a game industry", meaning that you are not doing anything novel, you're just there to turn the crank and make one more game come out of the system that is the same as all the other games coming out of the system. For example, an "indie" developer who ships yet another platformer is the less interesting case to me than a developer at EA who develops a novel AI system for their next massive game. The former didn't really push us forward at all, while the latter did.
Does that clarify?
- Casey
From watching Casey work I got the idea that you can't create original designs unless you can also create original technology. If you can only use a general purpose engine, whatever you create will be similar to all the other folks that use that engine.
What was that incredible game Jon Blow made where the player can stop time and run it forward and backwards? That is an example of something original that you'd never see invented by a person who can only use general purpose engines. Or how about where Casey created an entity system his own way, that no general purpose engine maker would ever consider adding? Graphics and lighting don't interest me much at all, but those kinds of things certainly do!
Edited by Mór
on