As a result of that failure , I wrote a section in my game design document on coding and naming conventions for me and whoever might help me.
Here is that section from my design document.
Any way I thought somebody might find this useful.
Naming conventions:
A tower defense game tends to be considered a small game easy to develop. Yet I can tell you this game will have quite a bit of development issues. That will move into advanced programming. It will have to compete against games made by hobbyists thru big dollar companies with hundreds of developers. Chances are new devs will join this project, or they may be periods of time away from sections of code that unless named and organized properly will become a bewildering maze of confusion.
Sort all assets and scripts in folders for each game object and scene, then as type.
Ie: Main Menu Folder has all subfolders for each object / node and inside of those folders subfolders with their assets. Main Menu> Exit Button> image folder and sound folder etc.
All node names and variables should be human readable:
Dont do this:
#a = player health
Var a=a+1
This is bad for us; it requires two or more lines of code and later may lose what does this mean as “a” means nothing outside of context. Because the comment does not follow you later in the scripts.
This is better:
PlayerHealth=PlayerHealth +1
This combines those two lines together and later on we know that PlayerHealth is the variable that contains the integer value of the player’s hit points.
Commenting:
If you are in doubt if you need to comment then comment. Too much comments is better than not enough. SO even if your variable and node names are readable you may forgot what a particular piece of code even does. Or why it exists. So comment.
PlayerHealth=PlayerHealth +1 #After a collision with the MoreLifeItem add 1 point of to the PlayersHealth
So ex
plain what your code chunk is doing and why with comments. I hate it when I find something I cannot figure out what it does as the variables are opaque and there is no commenting. Is this piece of code reliant another function or code- then reference it in comment and on the dev map. Otherwise it's like trying to balance a checkbook with no dates and no item descriptions. You may get a correct balance- but you have no idea what the money was spent on, where, or when.
Whitespace:
Space in GDScript is critical to understanding what goes with what function loop, as well as for human readability. Poor indentation will cause game bugs. Too little whitespace will make the game very hard to read. ANd you want to be able to read the game as easily as you can a novel. Otherwise it will suck for you doing debugging or hiring other Devs. So add two lines after end of functions etc. Add comment above function with brief explanation as well as the code.
Example:
# Called when the node enters the scene tree for the first time.
func _ready():
#setting value for healthbars
$Control/playerhealthbar.value=playerhealth
$Control/enemyhealthbar.value=enemyhealth
randomize() #this resets the seed for random functioning
cardID.shuffle() #this calls function to shuffle the cards
print(cardID) # for debugging purposes this prints to console current id of the card
#
next function runs here.
You may notice that the example is easy to ready, even for a non programmer as you will have artists, investors and others on your project which may need to see code for some reason, as well as yourself. The white space on bottom shows the logical end to the function and combined with plain English variables, good commentating, and white space the code becomes legible.
