Hey, everyone!
A new devlog is out! This one discusses my shift from a traditional C/C++ build system to an amalgamation/unity build system, and also a shift in my programming philosophy: Staying true to the idea that one must only do what is necessary for their project.
Hope you enjoy!
Devlog #10 (Under The Hood) Uploaded (3/2/2018)
Comments
Good stuff.
With regards to your "house factory" comment, I think everyone should read Acton's Last Inner Product. It's a "lessons learned" collection from past developers of the last few decades. Here's my favorite, and it happens to be the first listed:
It can be VERY valuable to learn a lesson the hard way, but arguably even more valuable if all game developers learn about our history.
P.S. Actually, these lessons learned should be on our wiki with a reference to the original post. From Gamasutra's submission page it seems they claim no right over the content that's written (unless I misunderstand), so I'll contact Mike to see if we can edit the post and put it up on the network.
With regards to your "house factory" comment, I think everyone should read Acton's Last Inner Product. It's a "lessons learned" collection from past developers of the last few decades. Here's my favorite, and it happens to be the first listed:
There are very few problems that cannot be better solved by having better context. It remains a common programmer error to attempt to make solutions too generic, to try to solve all problems instead of simply the one at hand. In doing so, nine times out of ten, a programmer will add additional contraints to the problem that will in fact make the solution worse in all cases.
It can be VERY valuable to learn a lesson the hard way, but arguably even more valuable if all game developers learn about our history.
P.S. Actually, these lessons learned should be on our wiki with a reference to the original post. From Gamasutra's submission page it seems they claim no right over the content that's written (unless I misunderstand), so I'll contact Mike to see if we can edit the post and put it up on the network.
Thanks for the comment/link, Abner!
That's a fantastic article by Acton and parts of it very much echo the transformation I've had as a developer throughout this project. As I mentioned in the video, the approach I've taken to problems as a developer has very much changed. I often take a look through game systems that I wrote several months ago and it makes my change in mindset very apparent.
As of now, the game's entity system is effectively a C-implementation of an object-oriented system (because at the time I wrote it, I was still very much thinking in an object-oriented way, despite my desire to move away from such thinking), and the growing pains of such a system become obvious when the details aren't hidden away from the programmer.
It has made me realize that when implementing this sort of system, the programmer isn't actually getting cleanliness, scalability, or anything else; the programmer is simply getting the illusion of all of that (and such an illusion can only persist for so long). The code seems clean, but the code isn't necessarily what's happening anymore when everything is abstracted to such an extent...
This is just one of many lessons I've learned from this project, and it is very much motivated by this community and its philosophy. Hopefully I can serve as an additional example of a programmer who has learned certain things the hard way, and also a programmer who, with a changed philosophy, has written performant software (both in life performance and in software performance).
That's a fantastic article by Acton and parts of it very much echo the transformation I've had as a developer throughout this project. As I mentioned in the video, the approach I've taken to problems as a developer has very much changed. I often take a look through game systems that I wrote several months ago and it makes my change in mindset very apparent.
As of now, the game's entity system is effectively a C-implementation of an object-oriented system (because at the time I wrote it, I was still very much thinking in an object-oriented way, despite my desire to move away from such thinking), and the growing pains of such a system become obvious when the details aren't hidden away from the programmer.
It has made me realize that when implementing this sort of system, the programmer isn't actually getting cleanliness, scalability, or anything else; the programmer is simply getting the illusion of all of that (and such an illusion can only persist for so long). The code seems clean, but the code isn't necessarily what's happening anymore when everything is abstracted to such an extent...
This is just one of many lessons I've learned from this project, and it is very much motivated by this community and its philosophy. Hopefully I can serve as an additional example of a programmer who has learned certain things the hard way, and also a programmer who, with a changed philosophy, has written performant software (both in life performance and in software performance).