Unknown Unknowns
3 months ago
In my short but intense programming journey, my most consistent obstacle has been misunderstanding how something works until going to implement the idea into the game. This seems to be a solvable problem, eventually, but my gaps in knowledge are slowing down my progress a lot. Every new addition takes a lot of trial and error, intense research, and rethinking concepts` out in a different way.
Godot 4 poses some hurdles because of it's newness; a lot of the lessons and examples out there are from version 3. Version 3 and 4 of Godot are substantially different, so most of it is out of date and deprecated. As free resources go, the best thing out there is the documentation itself, if you can make sense of the way it and Godot are both structured. ChatGPT has been relatively useful for debugging, but it has only had knowledge including version 4 for a few months now, and not up to the latest revision. Also, finding examples of what I want to build is nearly nonexistent, nobody is demonstrating pieces of the Tycoon/Management genre. Closest thing I've found is an RTS style, but none with more detail than the initial framework.
After a friend's suggestion, I opted to seek out paid professional tutorials. It has been hit and miss, but I have to give a shoutout to "Firebelley Games" on Udemy for being exactly the technical level I'm seeking. While the kinds of games he is making are not the style I'm going for, the way he explains and demonstrates concepts makes it clear he is sharing details about the fundamentals of Godot itself. If I can understand the system better, I'll design my own framework based on examples from other, more prominent engines and languages.
With many lessons yet to cover, already he has clued me into better ways of handling game elements that have been implemented. The structure that seemed logical at the onset is quickly becoming muddy and was constructed with a lot of false assumptions. I still need some answers about the mouse interfacing with menu items on multiple levels... a bit beyond the usual "Start, Options, Quit" type UI videos I seem to find. The menu system goal is to effectively build a simple version of Windows on top of the simulation while it continues to run in the background as everything continues to operate as expected. If you've played Prison Architect or any Chris Sawyer games, somewhere in the middle of those two is what I'm shooting for.
My current objective is to build a three system platform that handles controls/inputs, display, and simulation. Up until recently that was all one big goopy soup that had everything under one branch in the Godot Scene Tree. At present, I have the simulation and the UI separated, and just completed moving all of the existing controls over to its own new node. What lingers is getting the mouse and keyboard to recognize the mouse position and only interact with the appropriate layer, so if you're scrolling down a list in the menu it doesn't zoom in and out in the game behind the menu.
While there still isn't much visually to show off, (in fact the game is currently broken at the moment due to restructuring) the progress being made is in the form of my learning how to build this game before I actually build it. My goal with the current Mark 3 build is to have simplified versions of every system I'll need in the game. Mark 4 will take the lessons learned from that build and make the structure and layout designed for easy construction and more efficient processing of the game's operations. There may be many Marks before the actual Alpha, it all depends on how well all of that goes. If any Mark is good enough to refine, it can start taking shape into an actual, bona fide game!
Godot 4 poses some hurdles because of it's newness; a lot of the lessons and examples out there are from version 3. Version 3 and 4 of Godot are substantially different, so most of it is out of date and deprecated. As free resources go, the best thing out there is the documentation itself, if you can make sense of the way it and Godot are both structured. ChatGPT has been relatively useful for debugging, but it has only had knowledge including version 4 for a few months now, and not up to the latest revision. Also, finding examples of what I want to build is nearly nonexistent, nobody is demonstrating pieces of the Tycoon/Management genre. Closest thing I've found is an RTS style, but none with more detail than the initial framework.
After a friend's suggestion, I opted to seek out paid professional tutorials. It has been hit and miss, but I have to give a shoutout to "Firebelley Games" on Udemy for being exactly the technical level I'm seeking. While the kinds of games he is making are not the style I'm going for, the way he explains and demonstrates concepts makes it clear he is sharing details about the fundamentals of Godot itself. If I can understand the system better, I'll design my own framework based on examples from other, more prominent engines and languages.
With many lessons yet to cover, already he has clued me into better ways of handling game elements that have been implemented. The structure that seemed logical at the onset is quickly becoming muddy and was constructed with a lot of false assumptions. I still need some answers about the mouse interfacing with menu items on multiple levels... a bit beyond the usual "Start, Options, Quit" type UI videos I seem to find. The menu system goal is to effectively build a simple version of Windows on top of the simulation while it continues to run in the background as everything continues to operate as expected. If you've played Prison Architect or any Chris Sawyer games, somewhere in the middle of those two is what I'm shooting for.
My current objective is to build a three system platform that handles controls/inputs, display, and simulation. Up until recently that was all one big goopy soup that had everything under one branch in the Godot Scene Tree. At present, I have the simulation and the UI separated, and just completed moving all of the existing controls over to its own new node. What lingers is getting the mouse and keyboard to recognize the mouse position and only interact with the appropriate layer, so if you're scrolling down a list in the menu it doesn't zoom in and out in the game behind the menu.
While there still isn't much visually to show off, (in fact the game is currently broken at the moment due to restructuring) the progress being made is in the form of my learning how to build this game before I actually build it. My goal with the current Mark 3 build is to have simplified versions of every system I'll need in the game. Mark 4 will take the lessons learned from that build and make the structure and layout designed for easy construction and more efficient processing of the game's operations. There may be many Marks before the actual Alpha, it all depends on how well all of that goes. If any Mark is good enough to refine, it can start taking shape into an actual, bona fide game!