this is unity c sharp

'static' can also describe a class that has only one instance and you can't make instances of it. It can be used to make singletons to store variables.

Sure! I've actually created and sold a tech startup and helped tons of indie devs.

Can someone theoretically make it as a solo dev? Sure. Whether or not being an indie dev is viable for YOU is the real question. 

1) Indie Dev == Running a Business

So, the first thing to keep in mind is that being a dev involves a completely different skillset from running a business. Some people are happy doing both, some hate it.

A game studio - whether a whole team or just 1 person - still has certain requirements. Marketing, Accounting/Taxes, and Handling Legal Contracts are all a part of any business. When it comes to making a game, you have game programming, game design, art & animation, UI/UX design, sound effects, music... There are those rare people out there who have all these skills, but most people will have to hire, subcontract, or pay for pre-existing items. That requires recruitment, knowing local/state/federal laws, and managing payments. (For example, California's new "AB5" law turned a lot of freelancers into employees who are entitled to full benefits.) At the VERY least, you should work with a lawyer to ensure you aren't breaking any laws. I also recommend using an outside accountant.

2) Know Your Audience

Old business adage: If you are making a product "for everyone", you are making a product for NO ONE.

Even professional studios sometimes drop the ball on this. You have to know who your target audience is, how to reach them, and what will attract them to your game. If you wouldn't play your own game, you probably won't know enough about target audience to reach them. (This is why diversity is so important.)

Also, understand the state of the market you are targeting. If it is too saturated, you'll need to work harder to stand out from the crowd. This is why a lot of people get discouraged and think they "can't" succeed. You aren't going to succeed as a solo indie if you are directly competing with Disney/Activision/EA/Tencent. This is why I highly recommend you stay on top of industry business news (not just gamer news). Most of us rely on www.gamasutra.com to see what business deals and trends are happening. The key to any business's success is identifying a significant and underserved market.

3) Manage Your Schedule

It is easy to fall behind and get discouraged while working solo. Create a schedule and milestone list. This will help you to stay focused when you REALLY don't want to work on your project anymore.

4) Test, Test, TEST!

Get as many people as possible to try your game on as many of your target systems as possible. I had a colleague joke once that when we launched we'd discover that our game didn't work on computers that were grey. It was a joke on the fact that post-launch you will find your game breaks in the most bizarre ways and times.

Also remember that you are the expert of your own game, others aren't. They will play in ways you have never considered. Games are a form of communication, so you won't know if you are communicating correctly until people with 0 knowledge of your game try it for the first time. (As soon as they have tried it or had it explained to them in any way, they are "tainted" as a "fresh" playtester. So don't tell them anything on their first playthrough and get as many people as possible to be "fresh" playtesters.

Final Note:
Not knowing your personal background, this is just a collection of some of the most common points people need to learn. I'm happy to answer more specific questions if you have any.

I just wanted to note that as an adult professional (who recently got into game dev myself) doing the same kind of work schedule you have (nights and weekends), it is really refreshing to hear that you made it work, and gives me hope that I can too. I know that wasn't the intent of this post, but I thought I should share that it was helpful and inspiring to see. Thank you, and good luck on your endeavors.

Void "awake" runs at the start of the scene, but it runs BEFORE the void "start"

Ah, the engine question. First off, I think different engines are better suited for different needs and you should work with whatever you feel works best for you, your team, and your project. I'll go over my personal opinions of my top 4.

GODOT:
Godot is actually my personal favorite engine and the one I generally prefer to work in. I like that I am not beholden to corporate restrictions; it has a wide range of platform portability; and because it is 100% open source, I can easily modify it to suit the needs of whatever project I'm working on. I also think Godot is the best engine for professional 2D game dev. I think all of these advantages (plus it being 100% free) will help it take off in the 2D indie community.

UNREAL:
If you want to make a AAA (or AA) 3D game, it will probably be done in Unreal. (In fact, demand for Unreal skills are projected to go up by around 140% in the next year or so.) Recently, Unreal appears to be putting a LOT of effort into attracting indies and mid-sized studios (probably in a move to push the Epic store). In addition to increasingly great free asset giveaways, they have increased the amount you can earn before having to pay ANY engine royalties to $1million!

GDEVELOP:
For someone doesn’t know how to code and wants to learn game dev, this is a GREAT option! In fact, I’ve used this engine to teach game development to kids. It’s also great for throwing together quick prototypes and game jams. It’s similar to Construct (or to a lesser extent, GameMaker) but 100% free and open source.

UNITY:
I’ll talk about Unity’s pros in a moment, but you should know that while I think Unity’s ubiquity makes it necessary to know if you are a pro, I strongly dislike it.

I think (for now) Unity is a bit better for 3D game dev than Godot, and (for now) a bit easier to use than Unreal. BUT…I think Unreal is coming for them in the 3D space and Godot is coming for them in the 2D space. That combined with some infuriating recent decisions they’ve made solely to drive increased revenue for their IPO move…and, well…

For right now, Unity is solidly embedded in our industry due to years of great PR/marketing (and some hefty government grants). Many colleges teach Unity and many studios use it because it is what the incoming talent knows…which leads to college teaching it because it is an “in demand” skill.

BUT - I think that could change quickly as more studio heads become aware of Godot as a viable “free” alternative for smaller indie projects (studio heads and publishers are notoriously cheap). The AAA world already pushes Unreal, so medium-sized studios that want to appear AAA will likely jump on that train.
 

***************TL;DR: I won’t be buying any Unity stocks.

First: Thank you! I'm glad my advice is helping! =)

Second: the issue you described impacts EVERYBODY. (I'm doing this right now instead of working on my game...*whistles*)

There is a saying in game dev: "When you are 90% done, you only have the last 90% to go!" Making a game functional (you can play it under OPTIMAL circumstances) is very different from making a game usable (your entire audience can play it under most circumstances). I think the shift from functional to usable is where a lot of motivation for game dev goes in the trash. For many, they feel the "fun" parts are now done. Few people are as motivated to do bug fixes and menus as they are making cool game mechanics.

Also, while hindsight is 20/20 and it is always easier to do something a second time, there is a time and place to redo/rewrite/restructure code. (I've worked as a code optimizer, so I really get this impulse.) The important thing is to determine if the effort to "redo" something is going to make the rest of your project go smoother (or make important improvements to your project's file size/frame rate) or is it just an impulse based on a lack of confidence in your dev ability. If the former, it may be worth the effort to rework as much as is necessary. If the later, well...

The best thing you can do is create a milestone schedule for yourself and try to stick to that. This will keep you focused on what you NEED to get done. If you determine that redoing your code *is* necessary, then you can budget this in to your schedule. Sometimes seeing how much time you have to add to your schedule is enough to discourage yourself from doing it unnecessarily.

I've heard some indies talk about different ways to motivate themselves through the "slog" of completing a big game project. Some rely on encouragement from friends or other devs. Some use a personal reward/punishment system. (I once heard of a dev writing a substantial donation check to a group he loathed - I think the KKK - and giving it to his friend with instructions to mail the check if he hadn't completed his game by a certain deadline.) Less drastically, I've heard of indies setting up press-related events as motivation to meet a deadline. Others simply challenge themselves to meet arbitrary milestone deadlines. I've also heard of devs rewarding themselves with purchases they want. What motivates you, personally, is a very individual thing.

Please let me know if you want more info or were looking for something different.

First: Good for you! Learning code is ALWAYS a good thing. (I'm really curious what your "small period course" is.)

Second: When it comes to game dev, "hard coding" isn't always a bad thing. (I do it sometimes.) This industry...has a history of "hacking" together code. With the exception of massively multiplayer games, we generally aren't making games that are intended to withstand the test of time. Most games only have a shelf-life of a few months before it ends up in the "budget" bin and everyone has moved on to the next thing. Financially, we are perversely incentivized to NOT have our games last because we can sell "upgraded" or "remastered" versions later.

That said, if you want to be a AAA coder, I recommend getting into a good college. Digipen, MIT, Stanford, USC - that sort of thing. But even a decent state college can teach you what you need to be a better coder. But look for a school that includes both C++ and at least one "scripting" language in their curriculum (python, lua, etc).

As to how to code better, I'd need a bit more detail about where you are in your coding journey. What languages are you using? Do you know the main principles of coding (Variables, loops, conditionals, functions, etc...)? Or are you struggling with things like inheritance and using lists vs queues?

One rule of thumb I will give: generally the only "hard coded" numbers you should ever use are 0,1, & 2.
For any other number, 99.9% of the time you will want to set it as a variable at the top of your class/function.

Example of a bad use of "hard coding" a number:
       for (x=0; x < 150; x++)
Here the number 150 is a "magic number" because it isn't obvious why you wrote it. Maybe that is how many enemies you plan to have on screen. But what if you decide that is too many, or too few? You'll have to search through all your code to find and change the number.

Here's what it should look like:
       max_enemies = 150
       for (x=0; x < max_enemies; x++)
Here you are still using 0 as a starter number for your counter. This is generally fine. But 150 is no longer a "magic number".

Does this mean I NEVER hard code numbers other than 0, 1, or 2? No, I do it sometimes. But 9 out of 10 times, I end up regretting it.

Freesound.org
OpenGameArt.org

Or - make your own!
Audacity (https://www.audacityteam.org)
LMMS (https://lmms.io)
BeepBox (just Google it, Itch won't let me post the link for some reason)

As soon as you said "global Singleton" and "signal" I went, "Oh, a fellow Godot user!"
While these concepts exist elsewhere, they are not as commonly referenced in game dev - but they are staples in Godot.

Here is a random collection of tips and thoughts on how I organize things in Godot (my fav engine):

SINGLETONS:
Personally, I've been increasing my use of global singletons for optimization purposes. (For example, I use them for my audio library so I don't have to search everywhere to find a sound effect.) This also helps me front load some parts of my games at more appropriate times (like during menus) so my framerates don't drop.

I always have a "GLOBAL" script that holds certain library functions I want everything to have access to (like playing audio). My global singleton holds references to key nodes that I set upon loading. For example, I use "var CAMERA" in the global singleton and then the ready function in my Camera's script starts with "GLOBAL.CAMERA = self". This way, anything can easily reference the camera with "GLOBAL.CAMERA" without having to waste time referencing the tree root or figuring out how far down the tree I set my camera. I can move my camera up or down my tree during dev time and it will always be findable at runtime.

Other items I have done this with include: HUD, PLAYER, CURRENT_LEVEL, and DATABASE...

SIGNALS:
I like using the built-in signals, but for a lot of things, custom signals can make things harder to manage. I know it isn't the "preferred" way to do things in Godot, but I don't mind tightly coupling some things even though it reduces reusability. There are a lot of tradeoffs in coding: readability, speed, efficiency, reusability... We all have to choose what we want to prioritize with each script we write. For game mechanics, reusability isn't my highest priority. (That said, I have a growing folder called "Utilities" that I generally just copy-paste from one project to the next. So for *some* things I care about reusability.)

SUBNODE REFERENCES:
Anytime I want to reference a sub node in a script (eg: a sprite); I will create an onready variable at the top of the script.
"onready var MySprite = $sprEnemy"

Then I use the variable (eg: MySprite) in place of referencing with the "$". This way, if I later move or rename the subnode (which I do a LOT), I only need to change its reference once. Also, I use a consistent naming convention for both subnodes and subnode references (eg: the sprite for something is ALWAYS labeled as "MySprite"). This way, there is never any question what is being referenced and it makes script reuse easier.

LABELING:
I also recommend being mindful about folder use and naming conventions. In my current project, I have a folder called "Enemies" and everything in there has a name that starts with "Enemy_". I also have a folder named "Levels" and every item starts with "Level_" or in some projects "lvl". Personally, I prefer to keep my scripts in the same folder as my scenes rather than make one HUGE folder labeled "Scripts".

Use subfolders! Under my Assets folder I have sub-folders labeled "UI", "Audio", "Fonts", "Shaders", and "Art". Under "Art" I usually have subfolders like Enemies, NPCs, Player, Background, etc. Under "Audio" I have "SFX" and "Music" separated. I prefer to name my assets with what they are "red_spaceship_coneshape.png" rather than how they are intended to be used "level1_bkg_music.ogg" because I might change my mind about how it is to be used later.

ART:
As often as possible, I like to use black & white art assets and color them in using either shaders or the self-modulate function. this allows me to shift color pallets on the fly. I'll even have colors named in my GLOBAL script "MyBlue = Color(#41d7d7)" and then reference them "set_blink(GLOBAL.MyRed, GLOBAL.MyBlue)" for things like hit effects.

ANIMATIONS:
Tweens are your friend. Not really an organizational tip, just a fact.

Heartbeast also has a video on the program "Tilesetter" (which has a free "lite" version). This can help you generate tile sets like he uses.
Here's that video: (www.youtube.com/watch?v=SI3mZ3ynrTw)

A few quick notes about tiles in Godot: 

1) This configuration is only ONE way to do tiles. There are other formats Godot supports which can accomplish different effects (eg: animated tiles, randomized tiles [think of having 4 different "grass" tiles with slightly different images randomly placed to break up the repetition], etc.) You decide which tile configuration is best for your project (or your project's current layer).

2) Sadly, Godot doesn't have the most user friendly (or most powerful) tile mapping system. Thankfully, you can create tile map layers in other programs and import them into Godot. Good example: (www.youtube.com/watch?v=jFq4Eve_Db8)

3) Be aware that there is an issue in Godot's tilemaps where tiles may "flicker" on systems with Nvidia cards. You can fix this by sticking with GLES2, under Project > Project Settings > Rendering > Quality > 2D > enable both "Use Pixel Snap" and "use Nvidia Rect Flicker Workaround" by making sure the little check boxes are checked.

Tip 1: For whatever engine you are using, look up tutorials on YouTube. That's a great place to start!

Tip 2: As a beginner, I suggest working on a game that is VERY simple (something you *think* you can complete in 1-2 days) and make it in the same genre as the tutorials you are following. For beginners, it is easier to innovate on the micro-level (eg: tweaking how the gameplay feels) then to innovate on the macro (eg: creating new mechanics or genres). Once you are more experienced, you can challenge yourself to implement new and more unique ideas!

Tip 3: In English, you would be properly refer to yourself as a "programmer" or "coder", not a "programmist". (I know English can be arbitrary and confusing at times.)

Good luck!

This would depend on a lot of factors - what engine you are using, how you set up the controls, etc. Regardless, you'll need to have some kind of "switching" mechanism - an action the player can take to perform the switch (examples: press the space bar, click a button on the HUD, maneuver the character to perform an in game action, etc). Whatever this "switch" is should kick off an event that perform the control switch. One easy way to do this would involve swapping a Boolean flag (eg: isPlayerOneMoving = not isPlayerOneMoving), then use that Boolean to control what each controller inputs does.

Example: 

OnSpaceBar_Pressed():

     if (isPlayerOneMoving):
            PlayerOne.jump()

     else:
            PlayerTwo.jump()

you didn't name the boolean!