I would strongly suggest watching some better videos for inspiration (seriously though, incredibly impressive to see such an engaging explanation of something that may as well be magic as far as I'm concerned!)
Your technical knowledge is amazing, I'm always impressed with how much you manage to do and how you do it. I can't believe that you added raytracing aswell.
not to diminish the effort but raytracing/casting really isn’t technologically challenging, in fact its one of the easiest CG exercises to do, the big issue is that theres no real way to improve the performance :) Its perfect for this due to the low resolution though!
@@juliand3565 yup. To add onto it, the recent hype around it is just that modern GPUs now have dedicated hardware for calculating rays more quickly to the point that it can be used in modern 3d games to actually calculate lighting in real time. Raycasts have been around ever since doom came out (30 years ago), at the very least.
reasonably consistent, there's of course also a *lot* of work that doesn't end up in the video so it might not look like much. probably should have taken more breaks :)
Seeing vec4 in your code and the projections reminded me so heavily of my computer graphics class. You NAILED this. Great work! Keep it up, ill be watching everything you put out
I don't think it devalues the idea at all, but the "robot cultivating plants" pitch instantly reminded me of Grow Home & Grow Up. Very different though as the main focus of those games was unique (for the time) movement & climbing mechanics in 3d environments. Potentially some good research opportunities there!
I also got reminded of Grow Home! And also since jdh's game is underground it also reminded me of the anime Gurren Lagann. Combining them to in my head led to an image of a robot underground where the goal kinda is going to the surface and then to the sky and eventually to space :O
Amazing video! Recently I've gotten into game development (although I'm starting off with Unity and C#, I doubt I could handle the mental strain of making anything remotely playable in C++ my first try haha), and videos like these are what really pushed me to start in the first place! I'm probably about to use the wrong terminology, but there's just something so fascinating and inspiring about seeing how iterative the design process is; it takes months of dedicated work to achieve systems that most players will take for granted, and watching how you find solutions to functional camera and lighting systems makes it seem a lot less daunting! I was introduced to this channel through the Minecraft from scratch video and found this video through your tweet -- and I'm looking forward to seeing more progress on this game's development!
As someone who almost screwed off his own head from his neck while trying to code a freaking _pause menu window_ in a 2D game I'm building in my company's proprietary software (our own library is there but it has zero game-related features, only the most basic geometric operations as well as some QoL things such as a scripting language or array element handling, so it's kind of in between a framework and a dedicated engine), the phrase "taken for granted" has adopted a brand new meaning to me.
Dude, that looks really awesome! When I first saw those portals with the sick a$$ lighting, the bloom and the glowing particles _in pretty much all colors of the rainbow_ my jaw just about hit the floor! It looks really, _really,_ *really* good! I'm looking forward to playing your game already 😊
I find it super satisfying when a pixel art style game actually has consistent pixel size so epic work doing that as well as implementing things that wouldn't traditionally be seen in such a style like smooth camera interpolation
i might make a longer video about the setup at some point, but the driver behind everything is really just FZF (github.com/junegunn/fzf ) and the builtin LSP in NeoVim!
The voxel jitter fix reminds me of a technique used in (directional light) shadow mapping to essentially correct for the same problem there: as the directional light view frustum moves with the player camera, object rasterization to the shadow map produces aliasing artifacts which vary with the camera view, so shadow edges flicker and warble as you pan the camera around or move. In that situation you define a matrix projecting the center of the camera frustum to texel space, floor its x/y components, and project that back to world space before finally using the floor()'d frustum center position to produce the actual light view matrix. (I was not smart enough to figure this out on my own, and had to study the trick before properly understanding it, but you're clearly a different breed)
From the perspective of game designer who knows very mild amounts of code, i feel like most people can design a game but not all of the technical black magic required to make it work, so it's interesting to see the other perspective. Just a natural disposition i guess
@@simplexeon to work out an idea completely is harder as just programming the idea out. The programmer knows how to program it but onto how it should work? Well back to the design!
I really like your C++ coding style. I think you use the modern luxuries of the language whilst still keeping it readable and treating it as a C with Classes.
Man, that's crazy! I love the style and how much you went through to get to something you were happy with :] I was surprised to see someone come up with an idea so similar to mine, (and actually start making the game lol) really hoping it comes out fully fleshed out someday! We need more robot vs nature games out there haha
As always, an amazing and VERY inspiring video!! Also, maybe you can consider adding a "pinch of" factario by adding some mechanisms that help you to reach your goal.
Holy Shit, this looks fucking awesome. Really hope it gets finished, not like 99.9% of other game devs with dev logs (*cough* Karlson from Dani *cough*)
i'll be honest, the screen when palletization is off also looks really cool. the vibe gives me sort of a deep game with soft, subtle graphics that might show the way someone sees the world. i really hope that there's gonna be an option to be able to see the game without palletization, even if the graphics will be made around the idea there will be palletization, it looks like something that would change the graphics in such a subtle but impacting way
Am I the only one that find it so relaxing and mesmerizing just looking at all that code being written while listening to the soothing voice over telling about this amazing journey?
I’m absolutely in love with all of these concepts all together. I love the setting, the art, the whole idea of it being underground, the building, all of it. I really hope we’ll get a playable version soon at some point.
It's cool to see everything coming along and the game design falling a little bit more into place. One detail I'm not too sure about is the palette stuff. I feel it makes the game look like a heavily compressed video and I personally prefer having smoother colours. Of course, I'm not suggesting you remove it necessarily, but if you release the game, an option to disable it would be much appreciated.
I really think this color pallete lends itself way better to bright and lively scenes. You might want to merge it with another pallete for the dark underground environment.
5:25, more notes about this: - Deletes are good practice. But as long as I remember, if you don't customize any constructor, you don't need to write the defaults. Only write the deletes. - Why are you thinking about parent and child? Are you intending to make a linked list? What in a game would need that? Your default data struct should be std::vector. It's fast, flexible, easy to use, can be implemented by the compiler on the stack (hugely faster). Only change it for some special case if it proved worthful, like std::array for fixed-size, std::string for char container, std::deque for too much in/out from back/front, and so on. - Why are you using virtual? Just because it's an "User Interface" doesn't mean you need to implement it via an actual interface. It uses to be 15-17x slower, not bring relevant better usage. Each time you compile, both you and the compiler will always know exactly what are the UI features. So there's no need to use an interface. - I know std::optional may be easier to think. But it carries with itself the need to deal with branchings (ifs), making compiler's life harder. Compiler wants a straight road to run. With ifs, it tries to build several roads, to get rid of as many semaphores as possible. Whenever I make UI, a class holding all different UI objects has also a separated check-list, of all enable and/or visible state from each of them. Apps with valid-or-not objects have different points from which those objects start to have an always valid state. With optional, you'll have to convert them to not optional at those moments, or else you'll fill the compiler to the top, with unnecessary ifs. Eventually, you may say: _"C++ is bloated! Look how long it takes to compile!"_ - I wonder why...
Translation is the paradigm, the exemplar of all writing. It is translation that demonstrates most vividly the yearning for transformation that underlies every act involving speech, that supremely human gift.
I love how he acts like it's totally normal to make a custom cpu that can run his custom graphics card that runs a custom os that can (with some tweaks) run his >=20000 line game, diy minecraft, and allows him to code even more games. This guy is a master in hardware AND software.
I know this is early but I honestly think you're one of the smartest programmers out there, everything you've done so far literally looks so amazing dude.
Being a guy who has just started out with programming & CS in general, this all is not only overwhelming but also excessively intriguing. I have always loved the idea of lines & lines of text making a machine do what you want it to. Great video! I enjoyed the dev log very much!
The shimmering effect is very reminiscent of PS1 graphics, which relied on fixed point maths for its rendering and meant vertex pixels would shift as they crossed certain coordinate boundaries. A lot of people are nostalgic of that so it's not always a bad thing! ;)
One potential problem I see is that losing the character behind the isometric stuff is very possible (say while digging a tunnel), so the geometry needs to be turned transparent/translucent at least partly so the player can see through it?
This reminds me of making final fantasy and dragon warrior like games in pascal as a kid with 2 of my friends. We even wrote a bitmap art program, tailor made to our games. It made sprite and tile art sooooo much faster to make than using other dos art programs too. One nice feature is you could 4 way split screen and load in 3 sprites, then being able to copy sprite frame to 4 and it could even play the pictures as an animation. (Every non background element had 4 frames). We saved a lot of processing by making custom fonts for all the background tiles, so we could fake scrolling. The hardest part was composing PC speaker music, which in the battle procedure, we had to hand code, and basic bank switching to have 3 copies of the game, one with battle music, one overworld and a town song. Honestly, programming without libraries is sooooo freeing. I miss those days from decades ago.
4:30, even literal strings are slow to apply on the [ ] operator. If framebuffers is a double array of textures, I use to write things like that as: enum en_FrmBufs { GBUFFER=0, TRANSPARENT, MAX_FRMBUFS }; enum en_Textures { GBUFFER=0, NORMAL, DATA, DEPTH, MAX_TEXTURES }; std::array framebuffers; So if you ever need to pick 1 of them alone, use the enums. It'll just slide through arrays directly, the fastest way. But normally, you'll be busy by just using range loops. When you need to "handle" them, just (btw, you don't need to use this->, because by default the compiler will get things from the class) : for (auto &frmbuf: framebuffers) for (auto &texture: frmbuf) Framebuffer::make_attachment (texture.handle);
I love the graphic style! I also want to make a little survival sandbox game. I've gone through _so_ many programming languages, engines / frameworks, and styles trying to find something I like
Idea for dandelions and general plant sprite design: A tinge of bioluminescence. Allows for visibility, Adds to the magic of plants, helps the player understand why the robotanist likes plants so much. Could even become a resource thing. Maybe the light source the character has is fueled by the bioluminescent magic plants. Common plants like dandelions offer weak yellow light for a short amount of time. Maybe a sunflower would give strong yellow light for a medium amount of time. Rarer plants could give off like bright neon light. The player is on a quest to find the rarest plants both to decorate their base and to also allow them to have an easier and better time exploring
This is incredible! genuinely! I can't believe you did this, I can barely work with angles in my games, much less lighting effects, ray tracing, I can barely make a working camera. I'm in a similar boat because I use python and pygame to make games, but there is still a lot of stuff under the hood that's already done for me, so this is just genuinely baffling to see!
Suggestion: Glowing Flowers, they would feel magical, they can be plant for light and that can suit the theme. Also the new seeds could be obtained by finding small fields/underground biomes
Glowing flowers would probably be nice. Adds a little magic (fitting as the game revolves around flowers) and makes the player able to actually see them.
It seems like a combination of Equilinox and Planet Crafter in a sense, it sounds like a phenomenal idea and I don't think I've ever played anything quite like it
This is very impressive, I'm enjoying these dev logs. It would be cool if you could make a video going into more detail about the coding aspects and how you overcame some obstacles. Other than that, it's looking really good :D
This is really cool work, I always enjoy seeing how people encountering similar issues end up with their own unique and clever solutions. I was a dev on the now defunct game, Crucible, and we too had a character that was a plant loving robot. Its name was Bugg, but can you guess what its codename was? Yep "Robotanist." I'm sure we weren't the first to come up with that concept/name, but I'm pleased to see that we were on to something. :)
Maybe the robots blinker could change based on how it feeling or on its health. I feel like it would be cool and add lots of visual feedback if the light were to change to red when getting towards low health and start to blink faster the lower it goes.
Is there any chance you would make a video on the planning/ prep required/put in to make a project of this size? It would be really fascinating to see the methods you use to break this down and make it manageable
Channels like Game Makers Toolkit won’t ever reach you anything about game design. They just point out the obvious like: Telegraphing exists Choice based games have split paths And my personal favorite: Turn based games aren’t the same of non turn based games. As you can see, you’re better off just going off what you know for game design before eating channels like those. I’m sure there’s some good channels out there but I learned infinitely more by just watching other developers dev. Logs. There are some great ones by Devduck if your interested
This is the first time I'm actually watching one of our movies and at ~0:40 I already subscribed. I love your setup and it's what I also use. But probably the reason I subscribed has more to do with the fact that I relate to your struggles while game designing / programming. I wish you luck and hope to see great games from you! ;)
I don't know how much success you would have with that, or how much you'd enjoy it, but I'm just saying that if there was someone who would make quality tutorials or just learning materials about building an engine or other amazing stuff that you've done, it would really go a long way into helping enthuziastic young programmers (like me) getting into next level projects. And I'm not talking about some oversimplified step-by-step tutorials for beginners, as I don't find those very helpful.. Your videos are already really inspiring btw, I hope you know that
heeey a video from you, nice, can't wait to watch that (edit : very nice video, i learned quite a lot of things while watching it that will most likely be useful for me in some years, yay)
You are so incredibly talented! I love video games. I especially love programmers that create something new, to me it shows wanting more than just programming but art and innovation. Keep up the awesome work, I am always in awe at how complicated games are, and truly respect when one is dont well.
The first rule of design coders. Do not do design and coding same time. Desing first and then code. Design answers question about what to do and code how to do it, you can't do thous same time. You can cut both small spaces but do them at different times.
When you were talking about the shadows, the entire time I was thinking "raytracing, raytracing, raytracing" as a joke but then you actually did it and I was so happy. It looks awesome!
As someone who's trying to make a game solo, even with an existing game engine, I have no idea how to make the code do half the stuff I want it to, so it's really interesting to see the other perspective of not knowing how to design a game but being able to do all of the dark arts required to make stuff with that much code actually work.
I think your game concept has a lot of promise. I a gameplay loop where you learn how different elements of your ecosystem interact through experimentation and use that knowledge to make it self-sustaining would be very fun.
Robot, underground, growing plants? Sounds like a space colonization where automation is setting up shop in lava tubes on moon or mercury or what have you.
Was Grow Home/Grow Up one of the games that helped inspire your idea? It’s got a similar idea of finding different seeds and growing to get places and things to collect to improve your gear. If you haven’t heard of it you should check it out.
Hearing the idea for the game reminded me instantly of Waking Mars. Watching the rest of the video showed that this game is only somewhat similar to it, but I really liked Waking Mars, I recommend it.
I like seeing engine development begin to give way to game design! It's creating for a very unqiue and interesting project, makes me think it's like a isometric-top down Terraria game. Still, looks really awesome! I wonder what baddies will inhabit the cave ecosystem? Perhaps plant based monsters?
Amazing technical details, I would just suggest a better, more concise naming of the variables, by fully flashing out their goal. (ex. instead of diff_px -> pixel_difference), it might seem unnecessary, but after working in many projects, I can say that any extra info is more than welcome.
can you add more animation to the arms and legs? the feet and the hands are moving but I feel it would look better if the arms and the legs swung when you moved
looks cool! i have a mechanic idea - maybe the robotanist has to make power reactors and lighting in order to grow those plants instead of sun crystals. you could mine ore and stuff in order to fuel those reactors. and it doesn't have to be real fuels it could be fictional stuff.
Oh my god I know what you mean. It feels like every couple months I have some new half-baked idea for a game, work through the technical problems I'd need to solve to implement it, decide to do it all myself instead of finding a library or using unity or whatever, then I realize I have no idea how to turn my idea into actual systems and gameplay so I give up. Honestly it's still a fun process, and it's just a hobby for me so I don't really care if I never release a game. But still, looking through my graveyard of old projects really makes me feel some kind of way.
Design in principle is very simple but highly philosophical. The first step is simply to meditate on what something is. Do this for everything. Once you've defined everything as substances and essences, you then meditate on the effects in order to define an objective purpose, and from there, you apply the final step which is to apply a subjective purpose which is subject to the constraints that you defined with the objective purpose. _However,_ before you can meditate on what things are, you need to meditate on what you need. Necessity is defined by the end or final cause, and we can dichotomize necessity into relative and absolute. If something cannot be done unless such and such takes place, that is absolute; it is relative otherwise. In the context of algorithms, the only thing that matters is absolute necessity, and every program you write is an algorithm in essence. When some implementation is free of all relative necessity, it is optimal. Allow me to demonstrate this process with a simple example. I have determined the end I wish to achieve: to replicate the Mona Lisa with my own hand. What is _absolutely_ necessary to achieve this end? Well I've decided the means should be my hand. If you're already an expert painter: great, we can move on; if not, you will need to dedicate a significant portion of your time to mastering painting. If you had the precision of a robot in your hands already, you could just follow some instructions like a computer, and define the Mona Lisa as a series of strokes instead of points, but let's say this isn't like some dystopian future and say we don't have robot hands, then your only choice is to force the neurons in your brain to adapt to making precise motions with your hands, and that requires practice by absolute necessity. We are now masters at painting, and we now know the best tools for painting. In our time learning how to paint, all other necessity can now be trivially determined: the choice of canvas; the choice of brushes; color palette; pigment type; stroking techniques, etc. After thinking for a few minutes, you know all you need to replicate the Mona Lisa, so you do. In summary, design consists of three simple steps: 1. Meditate on what is necessary to achieve the end you desire. 2. Meditate on what makes those necessary things to be what they are. 3. Meditate on the relationship of the necessary things to each other with respect to both the general and the particular, and from there, a particular implementation can proceed. With respect to the general, you can create something as powerful as a well-designed software library or game engine; with regards to the particular, a well-designed program or game. By the way, I'd just like to disclaim any notion of designing something right the first time being easy. What I'm asserting is that the design process is easy, but it takes a while if you want to get it right. Prototyping can be an efficient way to figure things out, but prototype code shouldn't be in production environments; chad programmers toss their prototypes in the trash, assuming it's all garbage (and maybe dumpster diving a few lines of boilerplate to copy and paste), and just reimplement the design that they have now properly discovered ;)
I don't know how thought through this is, but I really like the idea of the blinker on the head: It would make sense to only activate it while not being in the range of a light source (maybe range of growing like Minecraft) because he can't see in the dark. The blinking could be made of repeating patterns depending on "emotions" of the robot (code for fear of enemies, enjoyment over finding rare crystals or "low battery"). This could be coupled with making the dark more dangerous, but more rewarding at the same time. Those patterns could also be useful for riddles of some sort (syncing patterns or smth) Since those are very rough sketches, you or anyone else in the comments already thought of similar stuff. Still I hope you can build up on them and continue to produce such high quality content (literally this is insane work!!)
![เจ็บที่ยังฮัก - ม่อน วรวิทย์ [ Official Mv ] จอนนี่มิวสิค](http://i.ytimg.com/vi/KALIGSRSjFs/mqdefault.jpg)
I would strongly suggest watching some better videos for inspiration (seriously though, incredibly impressive to see such an engaging explanation of something that may as well be magic as far as I'm concerned!)
no no, it’s better this way - when the gameplay ends up bad we will only have you to blame!
The man, the myth, the legend himself
bruh
What games did you architect, Adam?
@@3zzzTyle what color is your bugatti?
Your technical knowledge is amazing, I'm always impressed with how much you manage to do and how you do it. I can't believe that you added raytracing aswell.
Raycasting
yoo chadderbox
not to diminish the effort but raytracing/casting really isn’t technologically challenging, in fact its one of the easiest CG exercises to do, the big issue is that theres no real way to improve the performance :) Its perfect for this due to the low resolution though!
@@juliand3565 yup. To add onto it, the recent hype around it is just that modern GPUs now have dedicated hardware for calculating rays more quickly to the point that it can be used in modern 3d games to actually calculate lighting in real time. Raycasts have been around ever since doom came out (30 years ago), at the very least.
chadderbox
how consistent were you in these 3 months? Did you have lots of breaks in between or were you grinding the whole time?
reasonably consistent, there's of course also a *lot* of work that doesn't end up in the video so it might not look like much. probably should have taken more breaks :)
another question that I ask myself, had to refactor the code a lot, or hardly even touched the code already done?
@@chefaku everything is constantly being refactored. no code is safe!
the answer is simple: meth
@@jdh have you tried rust, if so will you ever use it in a project
Seeing vec4 in your code and the projections reminded me so heavily of my computer graphics class. You NAILED this. Great work! Keep it up, ill be watching everything you put out
I don't think it devalues the idea at all, but the "robot cultivating plants" pitch instantly reminded me of Grow Home & Grow Up. Very different though as the main focus of those games was unique (for the time) movement & climbing mechanics in 3d environments. Potentially some good research opportunities there!
huh, I've never heard of those games before! thanks :)
Reminds me of Wall-e. th-cam.com/video/veySlNgGMO0/w-d-xo.html
The music in that game is peaceful
I also got reminded of Grow Home! And also since jdh's game is underground it also reminded me of the anime Gurren Lagann. Combining them to in my head led to an image of a robot underground where the goal kinda is going to the surface and then to the sky and eventually to space :O
Amazing video! Recently I've gotten into game development (although I'm starting off with Unity and C#, I doubt I could handle the mental strain of making anything remotely playable in C++ my first try haha), and videos like these are what really pushed me to start in the first place!
I'm probably about to use the wrong terminology, but there's just something so fascinating and inspiring about seeing how iterative the design process is; it takes months of dedicated work to achieve systems that most players will take for granted, and watching how you find solutions to functional camera and lighting systems makes it seem a lot less daunting!
I was introduced to this channel through the Minecraft from scratch video and found this video through your tweet -- and I'm looking forward to seeing more progress on this game's development!
As someone who almost screwed off his own head from his neck while trying to code a freaking _pause menu window_ in a 2D game I'm building in my company's proprietary software (our own library is there but it has zero game-related features, only the most basic geometric operations as well as some QoL things such as a scripting language or array element handling, so it's kind of in between a framework and a dedicated engine), the phrase "taken for granted" has adopted a brand new meaning to me.
Dude, that looks really awesome! When I first saw those portals with the sick a$$ lighting, the bloom and the glowing particles _in pretty much all colors of the rainbow_ my jaw just about hit the floor! It looks really, _really,_ *really* good! I'm looking forward to playing your game already 😊
I find it super satisfying when a pixel art style game actually has consistent pixel size so epic work doing that as well as implementing things that wouldn't traditionally be seen in such a style like smooth camera interpolation
I would love to learn more about your NeoVim configuration, it seems that your workflow is really robust in it.
i might make a longer video about the setup at some point, but the driver behind everything is really just FZF (github.com/junegunn/fzf ) and the builtin LSP in NeoVim!
@@jdh broken link. Add a space after it, youtube thinks ')' is a part of the link.
@@jdh A video would be nice!
Just seen this after commenting the same thing +1
i wonder how did you put that terminal down in neoview
@jdh
The voxel jitter fix reminds me of a technique used in (directional light) shadow mapping to essentially correct for the same problem there: as the directional light view frustum moves with the player camera, object rasterization to the shadow map produces aliasing artifacts which vary with the camera view, so shadow edges flicker and warble as you pan the camera around or move. In that situation you define a matrix projecting the center of the camera frustum to texel space, floor its x/y components, and project that back to world space before finally using the floor()'d frustum center position to produce the actual light view matrix.
(I was not smart enough to figure this out on my own, and had to study the trick before properly understanding it, but you're clearly a different breed)
that's exactly where the trick came from!
'Turns out game design is harder than any programming problem.'
*(as a programmer)truer words have never been spoken
As a designer who's seen programmers do design, truer words have never been spoken.
Even though I disagree, I can respect your view point.
YES!
From the perspective of game designer who knows very mild amounts of code, i feel like most people can design a game but not all of the technical black magic required to make it work, so it's interesting to see the other perspective. Just a natural disposition i guess
@@simplexeon to work out an idea completely is harder as just programming the idea out. The programmer knows how to program it but onto how it should work? Well back to the design!
I really like your C++ coding style. I think you use the modern luxuries of the language whilst still keeping it readable and treating it as a C with Classes.
Very cool project ! Do you think you'll make the repo public someday ? I'd love to check out that engine
Man, that's crazy! I love the style and how much you went through to get to something you were happy with :] I was surprised to see someone come up with an idea so similar to mine, (and actually start making the game lol) really hoping it comes out fully fleshed out someday! We need more robot vs nature games out there haha
LES GO WE GOD MORE JDH! Love watching this stuff, been around since the beginning and cant wait to see more!
As always, an amazing and VERY inspiring video!!
Also, maybe you can consider adding a "pinch of" factario by adding some mechanisms that help you to reach your goal.
Holy Shit, this looks fucking awesome. Really hope it gets finished, not like 99.9% of other game devs with dev logs (*cough* Karlson from Dani *cough*)
You’re one part of the reason he hasn’t finished the game
@@spiderbat2089 ah yes, ofc. Thenn go ahead, explain yourself.
@@spekulatiu he hasnt completed it because so many people are complaining about it that the pressure is too much for him
@@DoodleBunnyTV i mean yea thats a reason. But i also didnt want to put him in a bad light, it just worked with the joke.
Or our boy Randy
i'll be honest, the screen when palletization is off also looks really cool. the vibe gives me sort of a deep game with soft, subtle graphics that might show the way someone sees the world. i really hope that there's gonna be an option to be able to see the game without palletization, even if the graphics will be made around the idea there will be palletization, it looks like something that would change the graphics in such a subtle but impacting way
Hell yeah, new jdh video just dropped
19:35, this is what we used to call "magic numbers"
The soft camera touch was simply.... hmmm satisfying. It helps easing the motion sickness that usually happens with full locked camera.
Am I the only one that find it so relaxing and mesmerizing just looking at all that code being written while listening to the soothing voice over telling about this amazing journey?
I’m absolutely in love with all of these concepts all together. I love the setting, the art, the whole idea of it being underground, the building, all of it. I really hope we’ll get a playable version soon at some point.
It's cool to see everything coming along and the game design falling a little bit more into place. One detail I'm not too sure about is the palette stuff. I feel it makes the game look like a heavily compressed video and I personally prefer having smoother colours. Of course, I'm not suggesting you remove it necessarily, but if you release the game, an option to disable it would be much appreciated.
Don't strain yourself too much, every video you upload is a treat.
The game is looking fantastic, I really like the concept and the name!
I really think this color pallete lends itself way better to bright and lively scenes. You might want to merge it with another pallete for the dark underground environment.
5:25, more notes about this:
- Deletes are good practice. But as long as I remember, if you don't customize any constructor, you don't need to write the defaults. Only write the deletes.
- Why are you thinking about parent and child? Are you intending to make a linked list? What in a game would need that? Your default data struct should be std::vector. It's fast, flexible, easy to use, can be implemented by the compiler on the stack (hugely faster). Only change it for some special case if it proved worthful, like std::array for fixed-size, std::string for char container, std::deque for too much in/out from back/front, and so on.
- Why are you using virtual? Just because it's an "User Interface" doesn't mean you need to implement it via an actual interface. It uses to be 15-17x slower, not bring relevant better usage.
Each time you compile, both you and the compiler will always know exactly what are the UI features. So there's no need to use an interface.
- I know std::optional may be easier to think. But it carries with itself the need to deal with branchings (ifs), making compiler's life harder. Compiler wants a straight road to run. With ifs, it tries to build several roads, to get rid of as many semaphores as possible.
Whenever I make UI, a class holding all different UI objects has also a separated check-list, of all enable and/or visible state from each of them. Apps with valid-or-not objects have different points from which those objects start to have an always valid state. With optional, you'll have to convert them to not optional at those moments, or else you'll fill the compiler to the top, with unnecessary ifs. Eventually, you may say: _"C++ is bloated! Look how long it takes to compile!"_ - I wonder why...
I'm getting into programming, and development. I love watching what others are doing.
Thank you!
Those raytraced shadows are mmm _chef's kiss_
Translation is the paradigm, the exemplar of all writing. It is translation that demonstrates most vividly the yearning for transformation that underlies every act involving speech, that supremely human gift.
I love how he acts like it's totally normal to make a custom cpu that can run his custom graphics card that runs a custom os that can (with some tweaks) run his >=20000 line game, diy minecraft, and allows him to code even more games.
This guy is a master in hardware AND software.
I know this is early but I honestly think you're one of the smartest programmers out there, everything you've done so far literally looks so amazing dude.
Being a guy who has just started out with programming & CS in general, this all is not only overwhelming but also excessively intriguing. I have always loved the idea of lines & lines of text making a machine do what you want it to.
Great video! I enjoyed the dev log very much!
The shimmering effect is very reminiscent of PS1 graphics, which relied on fixed point maths for its rendering and meant vertex pixels would shift as they crossed certain coordinate boundaries. A lot of people are nostalgic of that so it's not always a bad thing! ;)
3 months wait was worth it for this!
One potential problem I see is that losing the character behind the isometric stuff is very possible (say while digging a tunnel), so the geometry needs to be turned transparent/translucent at least partly so the player can see through it?
This reminds me of making final fantasy and dragon warrior like games in pascal as a kid with 2 of my friends. We even wrote a bitmap art program, tailor made to our games. It made sprite and tile art sooooo much faster to make than using other dos art programs too. One nice feature is you could 4 way split screen and load in 3 sprites, then being able to copy sprite frame to 4 and it could even play the pictures as an animation. (Every non background element had 4 frames). We saved a lot of processing by making custom fonts for all the background tiles, so we could fake scrolling. The hardest part was composing PC speaker music, which in the battle procedure, we had to hand code, and basic bank switching to have 3 copies of the game, one with battle music, one overworld and a town song. Honestly, programming without libraries is sooooo freeing. I miss those days from decades ago.
I'm in love with the art style and general feel of the game already
4:30, even literal strings are slow to apply on the [ ] operator. If framebuffers is a double array of textures, I use to write things like that as:
enum en_FrmBufs { GBUFFER=0, TRANSPARENT, MAX_FRMBUFS };
enum en_Textures { GBUFFER=0, NORMAL, DATA, DEPTH, MAX_TEXTURES };
std::array framebuffers;
So if you ever need to pick 1 of them alone, use the enums. It'll just slide through arrays directly, the fastest way. But normally, you'll be busy by just using range loops. When you need to "handle" them, just (btw, you don't need to use this->, because by default the compiler will get things from the class) :
for (auto &frmbuf: framebuffers) for (auto &texture: frmbuf) Framebuffer::make_attachment (texture.handle);
I love the graphic style! I also want to make a little survival sandbox game. I've gone through _so_ many programming languages, engines / frameworks, and styles trying to find something I like
Use SFML and C++ if you're making a 2D game
@@hneri1540 I'm not really into C++, I like Rust much more :) Thanks for the suggestion though!
Idea for dandelions and general plant sprite design:
A tinge of bioluminescence. Allows for visibility, Adds to the magic of plants, helps the player understand why the robotanist likes plants so much. Could even become a resource thing. Maybe the light source the character has is fueled by the bioluminescent magic plants. Common plants like dandelions offer weak yellow light for a short amount of time. Maybe a sunflower would give strong yellow light for a medium amount of time. Rarer plants could give off like bright neon light. The player is on a quest to find the rarest plants both to decorate their base and to also allow them to have an easier and better time exploring
This is incredible! genuinely! I can't believe you did this, I can barely work with angles in my games, much less lighting effects, ray tracing, I can barely make a working camera. I'm in a similar boat because I use python and pygame to make games, but there is still a lot of stuff under the hood that's already done for me, so this is just genuinely baffling to see!
the palettized lighting looks so lovely
your videos are epic. they are super entertaining and I love how you explain everything. honestly one of my favorite youtube channels.
Suggestion: Glowing Flowers, they would feel magical, they can be plant for light and that can suit the theme.
Also the new seeds could be obtained by finding small fields/underground biomes
You could make it so that the green bulb on the robot's head blinks faster the less health you have. I think that could look dope
If the Bee Movie taught me anything, it's that flowers need pollinators.
Also, that camera overscan trick was real slick, made all the difference!
18:15 when I noticed the cute little green blinking light on top of the robot botanist that made me really happy 😊
Glowing flowers would probably be nice. Adds a little magic (fitting as the game revolves around flowers) and makes the player able to actually see them.
That smooth camera movement is amazing. I saw that other video too by aartheficial, amazing stuff.
It seems like a combination of Equilinox and Planet Crafter in a sense, it sounds like a phenomenal idea and I don't think I've ever played anything quite like it
Your robot-underground-in-caves game idea gave me this really awesome image of a mixture of the anime Gurren Lagann and the game Grow Home
Great to see you flesh this out. It's really interesting seeing the problems you ran into with 3D isometric rendering.
This is very impressive, I'm enjoying these dev logs. It would be cool if you could make a video going into more detail about the coding aspects and how you overcame some obstacles. Other than that, it's looking really good :D
This is really cool work, I always enjoy seeing how people encountering similar issues end up with their own unique and clever solutions. I was a dev on the now defunct game, Crucible, and we too had a character that was a plant loving robot. Its name was Bugg, but can you guess what its codename was? Yep "Robotanist." I'm sure we weren't the first to come up with that concept/name, but I'm pleased to see that we were on to something. :)
Maybe the robots blinker could change based on how it feeling or on its health. I feel like it would be cool and add lots of visual feedback if the light were to change to red when getting towards low health and start to blink faster the lower it goes.
Is there any chance you would make a video on the planning/ prep required/put in to make a project of this size? It would be really fascinating to see the methods you use to break this down and make it manageable
Channels like Game Makers Toolkit won’t ever reach you anything about game design. They just point out the obvious like:
Telegraphing exists
Choice based games have split paths
And my personal favorite:
Turn based games aren’t the same of non turn based games.
As you can see, you’re better off just going off what you know for game design before eating channels like those. I’m sure there’s some good channels out there but I learned infinitely more by just watching other developers dev. Logs. There are some great ones by Devduck if your interested
you deserve 1 million subs NOW!!!! ur the best programming youtuber I've seen!!! And also you inspired me to create my own game! So thanks for all.
Finally, a new video, love your content! 💪💙
This is the first time I'm actually watching one of our movies and at ~0:40 I already subscribed. I love your setup and it's what I also use. But probably the reason I subscribed has more to do with the fact that I relate to your struggles while game designing / programming.
I wish you luck and hope to see great games from you! ;)
I don't know how much success you would have with that, or how much you'd enjoy it, but I'm just saying that if there was someone who would make quality tutorials or just learning materials about building an engine or other amazing stuff that you've done, it would really go a long way into helping enthuziastic young programmers (like me) getting into next level projects. And I'm not talking about some oversimplified step-by-step tutorials for beginners, as I don't find those very helpful..
Your videos are already really inspiring btw, I hope you know that
heeey a video from you, nice, can't wait to watch that (edit : very nice video, i learned quite a lot of things while watching it that will most likely be useful for me in some years, yay)
I love to see somebody who hasn't been coding for years be open about their code.
You are so incredibly talented! I love video games. I especially love programmers that create something new, to me it shows wanting more than just programming but art and innovation. Keep up the awesome work, I am always in awe at how complicated games are, and truly respect when one is dont well.
Awesome video! I really like how this game is turning out, and i'm excited about what you do next.
You could consider making the little green light on the robot the indication of health, so you don't need a healthbar!
The first rule of design coders. Do not do design and coding same time. Desing first and then code. Design answers question about what to do and code how to do it, you can't do thous same time. You can cut both small spaces but do them at different times.
When you were talking about the shadows, the entire time I was thinking "raytracing, raytracing, raytracing" as a joke but then you actually did it and I was so happy. It looks awesome!
Every great mistake has a halfway moment, a split second when it can be recalled and perhaps remedied.
As someone who's trying to make a game solo, even with an existing game engine, I have no idea how to make the code do half the stuff I want it to, so it's really interesting to see the other perspective of not knowing how to design a game but being able to do all of the dark arts required to make stuff with that much code actually work.
I think your game concept has a lot of promise. I a gameplay loop where you learn how different elements of your ecosystem interact through experimentation and use that knowledge to make it self-sustaining would be very fun.
this is fucking nuts. looks absolutely stunning can’t wait for the next devlog
Robot, underground, growing plants? Sounds like a space colonization where automation is setting up shop in lava tubes on moon or mercury or what have you.
This looks so good dude! I wonder what might be lurking in the underground that could hinder the robotanists flower finding progress
Watching you navigate you code with your neovim workflow is incredibly satisfying for some reason
Also I love the games name!
Was Grow Home/Grow Up one of the games that helped inspire your idea? It’s got a similar idea of finding different seeds and growing to get places and things to collect to improve your gear. If you haven’t heard of it you should check it out.
Hearing the idea for the game reminded me instantly of Waking Mars. Watching the rest of the video showed that this game is only somewhat similar to it, but I really liked Waking Mars, I recommend it.
been working on my own game/engine for a few months and this is really inspiring thank you
Amazing work!! Jdh is a Very talented programmer and computer scientist, hats off!
2 videos from jdh, christmas hit early
Bro its so good don't screwup. after you finish the engine and all the features, Just focus on the story and the gameplay
The best and most beautiful things in the world cannot be seen, nor touched... but are felt in the heart.
Making your own engine seems like a nightmare but it's so cool that you can do that
I'm just impressed you coded it all in neovim
bro, finally you are back, lets check this vid :)
I like seeing engine development begin to give way to game design! It's creating for a very unqiue and interesting project, makes me think it's like a isometric-top down Terraria game. Still, looks really awesome! I wonder what baddies will inhabit the cave ecosystem? Perhaps plant based monsters?
Amazing technical details, I would just suggest a better, more concise naming of the variables, by fully flashing out their goal. (ex. instead of diff_px -> pixel_difference), it might seem unnecessary, but after working in many projects, I can say that any extra info is more than welcome.
can you add more animation to the arms and legs? the feet and the hands are moving but I feel it would look better if the arms and the legs swung when you moved
Cool lighting and cute graphics!!
The background music really sounds like a Minecraft:Pigstep lo-fi remix to me... Love it (and the video too, keep it up!)
looks cool! i have a mechanic idea - maybe the robotanist has to make power reactors and lighting in order to grow those plants instead of sun crystals. you could mine ore and stuff in order to fuel those reactors. and it doesn't have to be real fuels it could be fictional stuff.
Oh my god I know what you mean. It feels like every couple months I have some new half-baked idea for a game, work through the technical problems I'd need to solve to implement it, decide to do it all myself instead of finding a library or using unity or whatever, then I realize I have no idea how to turn my idea into actual systems and gameplay so I give up.
Honestly it's still a fun process, and it's just a hobby for me so I don't really care if I never release a game. But still, looking through my graveyard of old projects really makes me feel some kind of way.
dope video dude you got my sub
Respectfully i NEEEED more! Chill vibes and I really like the aesthetic of your game, keep it up (or else)
Design in principle is very simple but highly philosophical. The first step is simply to meditate on what something is. Do this for everything. Once you've defined everything as substances and essences, you then meditate on the effects in order to define an objective purpose, and from there, you apply the final step which is to apply a subjective purpose which is subject to the constraints that you defined with the objective purpose. _However,_ before you can meditate on what things are, you need to meditate on what you need. Necessity is defined by the end or final cause, and we can dichotomize necessity into relative and absolute. If something cannot be done unless such and such takes place, that is absolute; it is relative otherwise. In the context of algorithms, the only thing that matters is absolute necessity, and every program you write is an algorithm in essence. When some implementation is free of all relative necessity, it is optimal. Allow me to demonstrate this process with a simple example.
I have determined the end I wish to achieve: to replicate the Mona Lisa with my own hand. What is _absolutely_ necessary to achieve this end? Well I've decided the means should be my hand. If you're already an expert painter: great, we can move on; if not, you will need to dedicate a significant portion of your time to mastering painting. If you had the precision of a robot in your hands already, you could just follow some instructions like a computer, and define the Mona Lisa as a series of strokes instead of points, but let's say this isn't like some dystopian future and say we don't have robot hands, then your only choice is to force the neurons in your brain to adapt to making precise motions with your hands, and that requires practice by absolute necessity.
We are now masters at painting, and we now know the best tools for painting. In our time learning how to paint, all other necessity can now be trivially determined: the choice of canvas; the choice of brushes; color palette; pigment type; stroking techniques, etc. After thinking for a few minutes, you know all you need to replicate the Mona Lisa, so you do.
In summary, design consists of three simple steps:
1. Meditate on what is necessary to achieve the end you desire.
2. Meditate on what makes those necessary things to be what they are.
3. Meditate on the relationship of the necessary things to each other with respect to both the general and the particular, and from there, a particular implementation can proceed. With respect to the general, you can create something as powerful as a well-designed software library or game engine; with regards to the particular, a well-designed program or game.
By the way, I'd just like to disclaim any notion of designing something right the first time being easy. What I'm asserting is that the design process is easy, but it takes a while if you want to get it right. Prototyping can be an efficient way to figure things out, but prototype code shouldn't be in production environments; chad programmers toss their prototypes in the trash, assuming it's all garbage (and maybe dumpster diving a few lines of boilerplate to copy and paste), and just reimplement the design that they have now properly discovered ;)
Keep Working on this, I feel this has a huge future!
For some reason, our YT recommendations are literally identical...
Great Video 👍
I don't know how thought through this is, but I really like the idea of the blinker on the head:
It would make sense to only activate it while not being in the range of a light source (maybe range of growing like Minecraft) because he can't see in the dark. The blinking could be made of repeating patterns depending on "emotions" of the robot (code for fear of enemies, enjoyment over finding rare crystals or "low battery").
This could be coupled with making the dark more dangerous, but more rewarding at the same time.
Those patterns could also be useful for riddles of some sort (syncing patterns or smth)
Since those are very rough sketches, you or anyone else in the comments already thought of similar stuff. Still I hope you can build up on them and continue to produce such high quality content (literally this is insane work!!)
thanks! and thanks for the ideas :)